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

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.

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

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.

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.

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

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 “set -e” which ensures that your script stops on first command failure. By default, when a command fails, BASH executes the next command. Looking at the logs, you might feel that the script executed successfully while some commands might have failed....

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

So, you believe there are bugs in your C/C++ code or you have encountered SEGFAULT while executing your code. What will you do? write a lot of printf statements at various places in your code under suspicion OR use gdb (GNU code debugger) This article is about Approach 2