Ashish

Glacier National Park in 4 days

Ashish on December 1, 2020

Glacier National Park, Montana is considered one of the most gorgeous national parks in the US. We went there in September 2020. It wasn’t snowing but the weather was still pretty erratic with random cold showers during the day. So, I would recommend going no later than August. Also, the east side, which has native American reservations were closed to prevent COVID-19 spread.

Dressing in at least three layers is highly recommended as the weather changes dramatically with heights and the time of the day.

Day 1

We entered from the western side, which almost everyone uses, and drove to the furthest possible point, Rising sun, on “going to the sun road”, the main road through the park.

Rising Sun

This also provides the best view of the second largest lake, St. Mary’s Lake.

Then, we drove westwards (back) to check out Sunrift Gorge. It can be seen via a very small hike.

Rift George

From here, we did a small hike to Baring Falls

Baring Falls

And then we did a long ~10-mile round-trip hike to Siyeh Pass.

Siyeh Pass Trailhead

Siyeh Pass

Driving further westward, we stopped and hiked to St. Mary’s Falls.

Saint Mary’s Falls

Day 2

We decided to do a long hike here, a 17-mile round-trip which starts from Logan Pass trailhead to go to Granite Park chalet. I would recommend doing a small 2-mile detour at the end to check out Grinnell Glacier. The hike is called Highline trail and true to its name, it is mostly along a cliff. I wouldn’t recommend it for someone with acrophobia.

We did see a couple of bears in this hike.

Highline Trail

The first bear we spotted on Highline Trail. It was eating berries.

Second bear we spotted on Highline Trail

Granite Chalet

Grueling hike to Grinnell Glacier

Grinnell Glacier

Some views on Highline Trail once the weather cleared up

After this hike, we decided to do a small ~2-mile hike to Hidden Lake overlook. The further ~1-mile one-way hike to the lake was closed due to the bear activity.

Hidden Lake Overlook

Day 3

On this day, we decided to do the touristy hikes of the park, starting with Cedars Nature Trail and further to Avalanche Lake. The lake is gorgeous and the hike is highly recommended.

Cedar Trail Waterfall

Avalanche Lake

I would recommend checking more waterfalls on the way back to Mcdonald Lake, the largest lake in the park.

Sacred Dancing Cascade

Mcdonald Lake – go to Apgar Visitor Center in the evening for this majestic view

Day 4

In the morning, we decided to check out the Hungry Horse Dam which can be accessed by a right turn just before entering the Glacier National Park.

Hungry Horse Dam

Then we did a ~10.5-mile round-trip hike to Otokomi Lake from the Rising Sun. The weather became worse as we climbed but the overall views still made it worthy of it.

On the way to Otokomi Lake

Otokomi Lake

Indeterminate Progress bar is an inferior UX design

Ashish on November 5, 2020

60 milliseconds is when we notice something isn’t immediate. Any user interaction, that involves sending data over the network or doing heavy computation on it, usually takes way longer than 60 milliseconds. So, we end with a progress bar. There are two broad categories of progress bars, one that shows the absolute/relative progress, a determinate progress bar, and one that does not an indeterminate progress bar.

Fancy but will this ever finish?

Now, here’s what’s the state transition looks like,
task started -> task progressed -> task finished/failed.

So, ideally, a software engineer should be implementing all these states. Most don’t. Some push the error handling to a later point. And then forget.

In such a situation, the indeterminate progress bar just stays there, spinning and spinning. While a determinate progress bar actually stops. So, a determinate progress bar not only communicates the speed of progress to the user but also, communicates if the progress has stalled.

So, why aren’t they more popular? Probably because it is a bit more work, you have to decide what the unit of work is. And if you are too off, the progress can look arbitrary. In my belief, even if the progress looks like a car navigating a bunch of speed breakers, it is superior since it communicates more actionable information to the end-user.

<span data-mce-type="bookmark" style="display: inline-block; width: 0px; overflow: hidden; line-height: 0;" class="mce_SELRES_start"></span>
Slow towards the end but the user can see the rate of progress and if the job is stuck

Things to do in Dominica – The nature island of the Caribbean

Ashish on November 1, 2020

Dominica, the nature island, is not easily accessible via the mainland United States. The airport is small and only propeller planes can land here.
The island is beautiful and is the only Caribbean island to have a rainforest. It is known to have 365 rivers.
The currency is East Caribbean Dollar (1 USD = 2.7 XCD). The USD has full acceptance, though.
Kalalau is the national dish. Its a soup made from Dakshin, and I would recommend trying it out.
Public transport is better than most other islands but is still limiting if your itinerary is jam-packed.
There are two towns, Roseau and Portsmouth. I would recommend staying in Roseau if you don’t have a rental car since most tours, taxis, and buses depart from there.
Most good activities are on the south side of the island. The south faces the calmer Caribbean sea while the north side faces a more turbulent the Atlantic Ocean.

How many source-code repositories should a startup have

Ashish on October 1, 2020

Recently, this question came up during the discussion. “How many source-code repositories should a startup have?”

There are two extreme answers, a single monorepo for all the code or repository for each library/microservice. Uber, for example, had 8000 git repositories with only 200 engineers!

I think both extremes are wrong. Too many repositories make it hard to find code and one single repository makes it harder to do simple things like testing, bisecting (to find buggy commit), deciding repository owners.

Here’s what I have seen works best.

Backend code – ideally, one single repository.
Frontend (web) code – one single repository. This can be separately tested and even outside contractors can access this. The web code is anyways shipped to the client, so, leaking it isn’t that big of a worry.
Mobile code – one repository per platform (Android, iOS, etc.) if there is no code dependency. Or one single repository if a common codebase like React Native or Flutter is being used. Again, those who access the mobile code won’t need access to the backend code. And given that this code in compiled form is sent to the users, there is less worry around leaking it.
Open-source code – One repository per open-source package.

As opposed to a monorepo setup, this setup makes it harder to make simultaneous changes to backend and frontend, or backend and mobile apps. And that should be the right behavior anyways. Since backend services and frontend can be, or eventually will be, deployed independently of each other. Mobile apps are deployed independently anyways, so, the backend has to provide backward-incompatibility for that.

Celsius vs Fahrenheit

Ashish on October 1, 2020

The US is one of the few countries where the temperature measurements are in Fahrenheit. Elsewhere, Celsius is the norm. Usually, when traveling, I want an approximate mapping. Thankfully, it is linear and easy to memorize.

To convert temperature in ºC to ºF – double and add 30
To convert temperature in ºF to ºC – subtract 30 and half

I’m looking for financial partners and would like to connect…

Ashish on September 15, 2020

A sample of LinkedIn requests I receive these days.

Hi Ashish, I’m the CEO of [redacted]. [redacted]. I’m looking for financial partners and would like to connect to see if we’re a fit.

Hi Ashish, I’m the CEO of [redacted]. [redacted]. I’m looking for financial partners and would love to connect! – M

Hey Ashish, I’m the CEO of [redacted] – [redacted]. I’m looking for introductions to financial partners and would like to connect to see if we’re a fit. – S

Hi Ashish, I’m the CEO of [redacted]. [redacted]. I’m looking for introductions to financial partners and would love to connect! – K

Three days in Cancun (Mexico)

Ashish on September 5, 2020

Cancun, or, more precisely, Cancún, is a coastal tourist city on the Caribbean (eastern) side of Mexico. There are two significant areas, Punta Cancun (tip of Cancun), also known as the Hotel Zone and Playa Del Carmen. We chose to stay in Punta Cancun. The Hotel Zone is walkable and you don’t need to rent a car if you are staying there. Buses are always available to go to other parts of Cancun though you rarely will.

Book Summary – Everybody Lies

Ashish on September 1, 2020

Everybody Lies Cover

The book takes a data-driven approach to analyze the world.

The two-step approach to big code modifications

Ashish on August 1, 2020

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…