Writing tests at an early-stage startup is always heatedly debated. If a function has one call, adding a unit test doubles the number of calls, this not only doubles the current work but even slows down future code changes 2X! Further, if the code is not finalized, it is legitimate to ask why even bother writing test code. Here’s a better way to write tests
RPC calls allow one service to call functions in another service as if it is a part of the same service. And unlike a REST API, one gets strong type checking. The two services can even be in different languages. gRPC is a great framework for implementing an RPC service. Another language-agnostic framework for making RPC calls is GraphQL . Many people don’t think of GraphQL that way, however, it can serve the same purpose. ...
While trying to install a custom exception handler to catch uncaught exceptions (crashes), I ended up writing
Java made a huge mistake of having no network timeouts. A network request can block a thread forever. Even Python did the same . The language designers should have chosen some conservative appropriate numbers instead. What’s surprising is that the Go language repeated it! Here’s a simple demo
What should this code print?
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.
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
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.
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. On only very few occasions will someone modify more than one of those simultaneously. Further, 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 and 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.