Programming

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....

Hugging Face is GitHub for machine learning models. Their on-the-fly model download scheme, however, is difficult from a DevOps perspective. Here’s how to disable it.

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.

If you create GitHub Actions via GitHub’s UI by going to the URL of the form `https://github.com///actions/new`, it provides templates for setting up the build. However, the template is broken. There are four problems with the default template

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.

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

On Android catching Java exceptions is easy via UncaughtExceptionHandler. Catching NDK crashes is a bit more convoluted. Since the native stack is probably corrupted, you want the crash handler to run on a separate process. Also, since the system might be in an unstable shape, don’t send the crash report to your web server or do anything fancy. Just write the crash report to a file, and on the next restart of the app, send to your web server and delete it from the disk. I ended up using jndcrash package for this.

After I wrote my previous post, some suggested that I can cut down the image size further by using a “scratch” image. And that’s true, “scratch i"s a reserved 0-sized image with nothing in it. And utilizing a scratch binary image did cut down the size of the final Docker image from 13MB to 7.5MB. Pretty good, right? Except the image cannot do an SSL cert verification because of the missing SSL certs!!! Bash 1 Failed to reach google.com: Get https://google.com: x509: certificate signed by unknown authority

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.

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.