Issue #19: 10 Reads, A Handcrafted Weekly Newsletter for Humans

GRIT is that mix of passion, perseverance, and self-discipline that keeps us moving forward in spite of obstacles.– Daniel Coyle, author of The Little Book of Talent

1. Microsoft is building a Chromium-powered web browser that will replace Edge on Windows 10: 10 mins read. This is a big news. Microsoft is building a Chromium based browser. This will replace their current Edge browser powered by EdgeHTML rendering engine. Now, the big question is this a good decision?
   1. For software developers this is good as they can expect same code to work in both Google Chrome and Microsoft new browser. This means less code to maintain and possibly fewer cross browser bugs.
   2. For the web as a whole, it might not be great news. With Microsoft adopting Chromium, Google is more powerful. The only other viable choices are Firefox and Safari. Firefox team also wrote a post on this topic and highlighted some of the dangers that lie ahead of us.
2. Faster and simpler with the command line: deep-comparing two 5GB JSON files 3X faster by ditching the code : 15 mins read. This post shows power of jq. jq is a command-line utility for working with JSON. It can pretty print JSON or you can use it to manipulate JSON. The team at Genius was facing an issue where they wanted to compare two big JSON files (5GB in size). They used jq to convert JSON files to a single format. Then, using diff they were able to find the difference between two JSON files. This is a good post that shows how to use a tool effectively to solve a problem.
3. The deepest problem with deep learning: 30 mins read. The author raises an important point that Deep learning is not the panacea. It solves certain problems but not suitable for every problem. I am not into AI but still I feel we need to understand limitations of a technology.
4. Software Sprawl, The Golden Path, And Scaling Teams with Agency: 15 mins read. I enjoyed reading this post. It covers an interesting challenge that high-performing engineering teams face. High performing engineering teams have the autonomy and mastery to use the best tools possible for the job. This usually means multiple programming languages, multiple databases, different messaging systems, etc. This works great when organization is small but sooner this makes your operation team overwhelmed. Charity lays down a five step process to control the software sprawl.  Read the post to know learn more about this topic.
5. The Forgotten History of OOP: 30 mins read. I have heard this multiple times in last couple of years in many different posts or talks. Each time I hear this, my mind start to think is Actor model object orientation done right. As mentioned in this post, Alan Kay(who coined object-oriented term) never thought object orientation means class based inheritance and polymorphism. For Alan, the key ideas in OOP are:
   1. Message Passing
   2. Encapsulation
   3. Dynamic binding
6. Cache warming: Agility for a stateful service: 15 mins read. This post talks about Cache Warmer utility built by Netflix. Cache plays a big role in almost all serious applications. Cache is the only way you can achieve low response times. There are times when you need to spin up a new cache cluster. In this post, Netflix engineers explained multiple approaches they used to build Cache warmer utility. I also built Cache warmer utility recently in one of my projects. It is good to learn how industry stalwarts are doing it. This gives new ideas that we can apply in our systems as well.
7. You Should Build your Next App on a Boring Stack: 10 mins read. The author summed up it well “The best stack is the one that works the best for you. One you know well enough to have your gut feeling point you in the right direction 90% of the time an error occurs. Because that is what will help you build reliable, working software. And in turn, earn your customer’s loyalty.”
8. Distributed Systems: When you should build them, and how to scale. A step-by-step guide: 15 mins read. An easy step-by-step post on how to build distributed systems. Main points in the post are:
   1. Most of your design choices will be driven by what your product does and who is using it.
   2. Focus on figuring out what people need, and try to come up with a solution to their problem, even if it has a lot of manual steps.
   3. Then think about ways to automate, spend your time coding and destroying, and use third parties where it makes sense.
   4. Don’t scale but always think, code, and plan for scaling.
   5. Build your system step by step, don’t address system design issues based on features that are not mature yet, and finally always try to find the best trade-off between the time you will spend and the gain in performance, money, and lowered risk.
9. React Native at Picnic: 10 mins read. The team at Picnic shares why they decided to use React Native instead of Native mobile app or PWA.
   1. An important requirement for the new application was that there should be no device or operating system lock-in
   2. Needs to operate well under uncertain networking conditions. Hence, offline support is very important
   3. We decided to use TypeScript instead of Flow
   4. For state persistence, we use redux combined with redux-persist for offline support
   5. On the UI-side, we use styled components for styling and storybook to document our UI components. Snapshots are automatically generated for each story by using StoryShots and React Native Storybook Loader.
   6. Any argument about syntax, we defer to Prettier.
   7. Finally, as the cherry on the cake, we use husky to run pre-commit and pre-push hooks that verify that all code that we check in is up to the standards that we have set for ourselves.
10. How to Enjoy Life: 15 mins read. I could relate to each and every word written by the author. Life is all about enjoying small little things. Most of the time it is just the way we look at something. Author writes, “The habit of taking even mild pleasure in such tasks would be life-changing, because most of what we do during a typical day isn’t done for enjoyment’s sake: laundry, exercise, office work, dishes, dusting. We do these things because they make life better in some less immediate sense; they’re rewarding, but not necessarily as you do them.”.