Programming

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.

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

It is impressive to see the amount of similarity which exists in Swift, Kotlin and Go, the three new languages for iOS, Android, and server-development respectively. Consider a simple, Hello World program. Swift Swift 1 2 3 4 5 func printHello() { // Type automatically inferred to string let name = "Ashish" // let declares a read-only variable print("Hello world from \(name)!") } Kotlin ...

When the code runs on your servers, you have much more control over the “context” in which it runs. On the mobile devices, the device OS and the user control the context. This difference leads to some subtle implications. One significant set of differences comes from the lack of control of the platform. For server-side code, one can choose from a wide array of languages. For the mobile code, however, the best choice would almost always be the one dictated by the platform - Java/Kotlin on Android and Objective-C/Swift on iOS. Further, for the server-side where one can stick to a particular version of the language. In the case of mobile, the platform controls the language version. Same goes regarding the hardware choices - one can choose to use different types of server machines specialized in handling those jobs, eg. GPUs for math-intensive computes. While for the mobile-code, one had to write a good enough fallback to support a wide-enough set the devices. Similarly, the server-side has to rarely worry about the server killing a running process while it is normal for mobile OSes to kill backgrounded processes eventually. ...

One argument which some people might give in favor of using tabs is that it allows the viewer to decide how the code should appear to them. And hence, it separates the logic (indentation) from its appearance. The biggest flaw in that argument is that it renders the concept of line length limits meaningless. Line length limits and the associated rules of wrapping bring a good structure to the code. Someone looking at a piece of code with 3-levels of nesting and tab-length set to 8 will see a very different line length from someone using a tab-length of 2. Always expand tabs.

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.

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

A small list of GCC Hacks g++ -o helloworld helloworld.cc produces helloworld binary from helloworld.cc C++ file. use -Wall switch turns on all warnings(potential errors) in the code (like unused variables) g++ -E helloworld.cc generates output code after the pre-processing stage.