Computer Science

 For the last couple of months, I have spent a long time researching entropy. It would be an understatement to say that there is absolutely no law that governs our existence as the second law of thermodynamics. The second law, however, only hints towards entropy. The third law of thermodynamics defines it. I hope you are aware of what entropy is. Sparingly, this is how we define entropy: Entropy is the total number of possible arrangements of particles in a system. As per the second law, the total entropy of an isolated system can never decrease. There is a striking similarity between entropy and information. If you are a computer scientist, you might know about Maxwell demon's paradox which was solved by information theory in the late 20th century. The solution claimed that the thought experiment for the paradox violated the second law of thermodynamics and hence not applicable. The paradox is still being discussed and debated even today. I am not going to talk about the paradox

 Recently I have earned readability (a Google certification for language expertise) in Java and JavaScript. Over the past few months, I have been a readability reviewer for most of the code that is usually checked in by my team to Google's codebase. I am an exhaustive code reviewer. I only accept code with the highest standards and best practices followed (Okay, enough of blowing my own trumpet!). One of the most popular questions that I usually receive is - "Shall I add a comment here to make things clear?". Most of the time my answer is a clear NO ! I am adding this small write-up to explain the reason. I really believe that writing code is very similar to writing a very simple story without any twist. The variables are the characters. Expressions provide a characteristic feature to a character. Each function narrates a conversation between variables much like an act in a play.  While reading a novel the reader's mind tries to guess what could be coming next. The re

Over the last 100 days, my learning curve has been extremely steep. Taking notes has been my habit ever since the 1st year of my college. I always love to write down things that I have learned. Jotting down notes gives me the final confidence about the things that I have learned. It also helps me in quickly ramping up the concepts again when required.  I have written over 50 notebooks containing notes related to my profession, i.e. Computer Science and several more on other areas of interest. I have kept them very carefully and carry each one of them wherever I relocate to (mostly in the hope that I will get a chance to go through them one day). When I look back now, I see that my notes suffer from some serious problem: Outdated information:  Since computer science is an ever-changing domain, most of my notes are now outdated. A few notes like those related to C++, Java, Algorithms, and Design Patterns are still good enough. Other notes like that on Hyperledger (a blockchain framework)

So, I am a Software Engineer at a reputed firm and still fell for the trap of fall-through feature of the switch-case statement. Rule of thumb: Starting from the matched case, all statements are executed, unless a break statement is reached. After the break statement, the control is transferred to the statement next to the switch-case block.  Here are some examples to test your understanding of switch-case: The output of the example is AB . This is because there is no break statement and so all the statements are executed after the first match of case 0. The output of the example is BCD . This is because there is no break statement and so all the statements are executed after the first match of case 1. The output of the example is AB . This is because there is a break statement at the end of case 1 so, after the first match at case 0, all the statements are executed till the break statement. The output of the example is AB . This is because there is a break stateme

Recently, I came to a very strange issue in Android development and I wish to share a very important lesson. As an Android developer, you might be knowing that most of the crashes are related to lifecycle events of Activities and Fragments. Moreover, most phone manufacturers patch the original Android system to come up with their own versions. Such versions might have a hostile kernel which may kill Activities more frequently to claim more free space and faster performance for foreground apps. This makes Android development difficult as you have to check for each of the edge cases that may occur. One of the best ways to debug such crashes is to use the " Don't Keep Activities " feature of the development mode. This kills the Activities and the fragments as soon as the app goes to the background. Enable this mode and start your app and navigate through all your Activities and Fragments. If you get no faulty behaviour, then your app is of quality-at-par. Let's

UI rendering speed has always been a key for evaluating a new technology. The lesser is the rendering time, the more preferable is the technology. In the recent times, React native has become very popular for developing native apps. Such apps are truly native and way different from similar other technologies like Xamarin and Cordava. I got some time to evaluate how React Native compares to Android SDK. TLDR: As you might expect, Android SDK outperforms React Native by a huge margin. But React native technology is slowly catching up (most of the credits goes to the amazing diff rendering technology which forms the core of React). React native is efficient enough for apps with small number of UI components which could be rendered within reasonable time. Performance comparison Emulator used for evaluation Model - Google Pixel 2 API Level - 24 Resolution - 1080 x 1920 (420 dpi) CPU - x86 Target - Android 7.0 RAM - 1536 MB Evaluation criteria We will be creating a large