Android: Don't use stale views

In MusicSync, one of the views became complex and too slow to be inflated on the UI thread. So, I decided to do some Pooling around it to inflate it on the background thread and use it on the UI thread. This made the UI snappier, reducing multiple-second load times when opening some folders. However, soon I ended up with an edge case where re-opening the activity (and not the app) led to a semi-functional app. This edge case is hard as it gets triggered only in particular scenarios where the user destroys the activity via swipe up. At the same time, the app keeps running due to the attached foreground service that’s playing the media. And on activity re-creation, I got stale views! ...

When to commit Generated code to version control

Generated code, ideally, should not be committed to version control. Committing generated code can sometimes speed up testing and code generation but it is a design smell. It is better to cache generated code via CI caching. Committing generated code to version control is the worst as it is hard to even detect the difference. However, there are a few specific circumstances where committing generated code/config/data to version control is worth it. ...

How to setup Go packages under monorepo

Let’s say you want to have two Go packages pkg1 and pkg2 in a monorepo setup. Here’s what a good project structure would look like.

Test changes to CircleCI config locally

Rather than pushing the code to a remote branch and then testing via Circle CI servers, it is best to run the tests locally first and make them work. Here’s how you can do that.

React Native

There are tons of hyped-up claims surrounding React Native that are worth addressing. The reasons why companies run for React Native are usually, We already use Javascript for the website and now, we can build apps in that as well. We can use one codebase for Android, iOS, and web apps. Or at least, Android and iOS apps. Facebook uses it

How many source-code repositories should a startup have

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.

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.

Consoles by Google

A single developer has to sometimes deal with 7 different consoles by the same company…

The first two statements of your BASH script should be...

Sh 1 2 #!/usr/bin/env bash set -euo pipefail The first statement is a Mac, GNU/Linux, and BSD portable way of finding the location of the bash interpreter. The second statement combines ...

File size should always be of "long" type

Java 1 2 3 int getTextFileSize(String fileName) { return (int) (new File(BASE_DIR, fileName).length(); // WRONG } A 32-bit signed int can deal with ~2GB worth of data. And if your code is not going to deal with files larger than 2GB, why worry? But what if someone wants to use the same code for a video file some day? Or What if someone writes another code to iterate over all the files in the BASE_DIR directory? Most likely they will be inclined to use int for the final sum as well. Adding integers in most languages results in int and automatic overflows into a negative number (and even worse, back to a positive number). The caller code might think that BASE_DIR does not exist. Therefore, the best future-proofing is to never have file size stored as an integer. Even, Android platform got it wrong with StatFs#getBlockSize and corrected it by adding StatFs#getBlockSizeLong. ...