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

The total time to read this newsletter is 165 minutes.
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.”.

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

The total time to read this newsletter is 130 minutes.
Fortune favors the prepare mind. — Louis Pasteur
  1. Three Sales Mistakes Software Engineers Make: 15 mins read. This post by PipelineDB folks talk about three mistakes sales mistakes software engineers make. I myself find it difficult when I have to take part in any sales initiative. The truth is we all have to sell. Sales do not always mean selling a product. It could be as simple as sharing your idea with the audience. It requires social skills that most software engineers lack. This post talk about three sales mistakes:
    1. Building a product before validating the market for it. This is part of the lean philosophy. I don’t think it is always feasible that you will have an audience with which you can validate your idea. So, I think in some cases it makes sense to building a functional MVP and drive from there. The MVP should not take more than 3 months.
    2. Talking instead of listening. The key message here is that listen to your audience and ask open ended questions. Some example of questions you can ask:
    3. How do you think about this problem?
      1. To what extent is this a priority?
      2. Why are you interested in this topic?
      3. .. Etc
    4. Mistaking interest for demand. Until you get money in your account your work is not done. IBM salespeople use BANT to qualify sales lead.
      1. Do they have enough budget to purchase the product?
      2. Do they have the authority to make the purchase?
      3. Do they need your product?
      4. Will the transaction be completed in a timeline that is acceptable to you?
  2. Amazon’s HQ2 Spectacle Isn’t Just Shameful—It Should Be Illegal: 20 mins read. This is yet another story of corporate getting things the way they want. They take billions of dollar subsidy from the government and return quite less. It is true in all parts of the world. In India, we have seen loan worth crores of rupees given to corporate. When the time comes to return back, system allows them to get away easily. All governments are hand in glove with corporates. We just don’t matter.
  3. Cloud Computing without Containers: 15 mins read. This looks interesting. I thought containers are the best we can go. But, as mentioned in this post, there are other possibilities like Isolates that can provider more efficient and economic alternatives.  This post does a good job comparing how Isolates compare against AWS Lambda that underneath uses containers. I will dig deeper into it more. Overall, a great post by Cloudfare folks.
  4. Things I learned from working at Shopify: 10 mins read. This is a great post by Budi Tanrim, a software engineer at Shopify. In this post, he talked about why he left an amazing job at Shopify to go back to Indonesia. Few points from his post that resonated with me:
    1. Come with a learning mindset: I often go for consulting assignments and there is always a tendency in me to come up with solutions before understanding the problem statement well enough. As he mentioned in his post, try to first understand the context and then think about solution.
    2. Be comfortable with being uncomfortable: When life events do not go as planned don’t get uncomfortable. If you get stressed then things will get more worse. It is always better to take a step back and think about the situation again.
    3. Prepare before presenting your work: This is an essential if you want to make an impact. Many time right words doesn’t come out at the right time so preparation helps a lot.
    4. Make decision log to have firmer decision: I also started doing it but I am not consistent. I agree with Budi that it is essential to document your decisions. The time you spent today in documenting your decision will serve you tomorrow when you might need to explain your rationale.
  5. What would a message-oriented programming language look like?: 10 mins read. Author thinks answer is Erlang. I have not worked with Erlang but I have used Akka with Scala in the past. Erlang like Akka is based on Actor model and when you work with actor model different objects communicate with each other using message passing. So, may be the answer is the language that has support for Actor model.
  6. Lessons from the data lake, part 1: Architectural decisions: 15 mins read.This post by AutoTrader engineers goes over the architectural decisions they took in building their own data lake. They started with on-premise solution but soon faced series of operational issues. The author writes Cluster computing on-premises is hard and expensive, cloud is easier. After failing with on-premise solution, they decided to build a new solution using Amazon S3 and Apache Spark delivered through AWS EMR solution. They used Terraform for provisioning cloud resources. They build five different zones to impose structure on their lake. They confined data to five ‘zones’ – in practice, five S3 buckets – named transient, raw, refined, user and trusted.They used Apache Avro for achieving schema on read.
  7. There’s Seldom Any Traffic on the High Road: 5 mins read. Another meaningful post on Farnam Street. This post makes an important point of not reacting when someone behaves rudely of you. As author writes, She was being rude. Yes. But that wasn’t the best version of her. I see the value of learning this skill. Making enemies is expensive. Sometimes you don’t even realize how expensive.
  8. Peeking under the hood of redesigned Gmail: 15 mins read. This post does a good analysis of performance issues with new Gmail interface. Using the tools available in Google Chrome, author was able to find possible reasons for bad performance of Gmail. It is sad that Gmail team does not use the facilities provided by Google’s own browser. I will recommend reading this article as you can apply the same learning for your website as well.
  9. Dealing with significant Postgres database bloat — what are your options? 15 mins read. When data is updated or deleted in Postgres, new data is written. The old data then needs to be vacuumed. That unvacuumed data is known as bloat. Here’s a look at how you can deal with it.
  10. Scalability Worst Practices: 10 mins read. This is an old blog published in 2008. The worst practices are still applicable today. So, give it a read.

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

  1. Database Isolation Levels And Their Effects On Performance And Scalability: 10 mins read. It is always good to refresh the foundational concepts. This post covers database isolation levels:
    1. Read Uncommitted: This level allows one transaction to read uncommitted data written by another transaction. This isolation level allows dirty reads.
    2. Read Committed: This level allows one transaction to read data committed by another transaction. PostgreSQL uses READ COMMITTED as the default isolation level.
    3. Repeatable Read: This level ensures that during a transaction you are guaranteed to read the same data that were committed when the transaction was started even if you make multiple read calls. MySQL uses this level as default.
    4. Serializable: This isolation level ensures that all transactions occur in a completely isolated fashion, meaning as if all transactions in the system were executed serially, one after the other.
  2. How Sharding Works: 20 mins read. Database sharding is a complex topic to master. There are so many database and they all handle sharding differently. This post gives a good introduction to sharding and different ways sharding is implemented by different databases.
    1. Algorithmic sharding: This is implemented at the client side using an algorithm like hash(key) % number of servers in the database cluster
    2. Dynamic sharding: This is implemented using a locator service. Clients make call to locator service and it tells them which node to talk to.
    3. Entity groups: This approach stores related entities in the same partition to provide additional capabilities with in a single partition. This is a popular approach to shard a relational database.
    4. Hierarchical keys and Column-oriented databases
  3. Kubernetes for personal projects? No thanks! : 10 mins read. The article goes over reasons why you shouldn’t run Kubernetes cluster for a small project. I agree with the point. Your goal should be to build application rather than fighting with infra. I found Docker compose based deployment sufficient for my side projects. I provision a docker machine on AWS and then deploy containers using Docker compose. It works great when you are small. I think the same argument for Microservices and Monolithic applications. Don’t use Microservices architecture for small projects.
  4. Rate limiting for distributed systems with Redis and Lua: 15 mins read. This post explains how you can implement API rate limiting in your application. It shows how to do that using Redis and Lua scripts. It covers two use cases for API rate limiting 1) rate limiting upstream clients and rejecting calls above the limit 2) rate limiting downstream clients to ensure that they can maintain allowed calls per second.It uses Token Bucket and Leaky bucket algorithms to meet the use cases.
  5. A brief history of High Availability: 20 mins read. This article covers the history of how databases have evolved to support availability and consistency. It covers Active-Passive, Active-Active, and Multi-Active approaches to design available database clusters.

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

Hello All,
Here are 10 reads I thought were worth sharing this week. The total time to read this newsletter is 165 minutes.  This week has stories on writing, remote code execution on Facebook servers, peter principle, Java 11 ZGC, Serverless patterns, PostgreSQL fast column creation, and few more.
Leadership is nature’s way of removing morons from the productive flow. – Dilbert

Continue reading “Issue #16: 10 Reads, A Handcrafted Weekly Newsletter for Humans”

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

Hello All,
Here are 10 reads I thought were worth sharing this week. The total time to read this newsletter is 190 minutes.  This week has stories on performance cost of containerization, how Slack built a scalable service for handling user preferences, productivity, security,  shallow reading, ACID transactions, and few more.
Whether you think you can, or you think you can’t – you’re right — Henry Ford

Continue reading “Issue #15: 10 Reads, A Handcrafted Weekly Newsletter for Humans”

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

Hello All,

Here are 10 reads I thought were worth sharing this week. The total time to read this newsletter is 195 minutes. This week newsletter has stories on bullshit web, CAP theorem, slow thinking, productivity, faster JSON parsing with Stanford Sparser, Serverless, Shopify tech stack and few more.

It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away. – Antoine de Saint Exupéry

Continue reading “Issue #14: 10 Reads, A Handcrafted Weekly Newsletter for Humans”

Issue #13: 10 Read, A Handcrafted Weekly Newsletter for Humans

Hello All,
Here are 10 reads I thought were worth sharing this week. The total time to read this newsletter is 130 minutes. This week newsletter has stories on Firebase, how to manage your engineering superheroes, service discover, habits to adopt in your life, how to do full text search with PostgreSQL, being a remote developer,  few more.
For every complex problem there is an answer that is clear, simple, and wrong — H. L. Mencken

Continue reading “Issue #13: 10 Read, A Handcrafted Weekly Newsletter for Humans”