The time to read this newsletter is 150 minutes.
The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn and relearn. — Alvin Toffler
- The Hard Truth About Innovative Cultures: 20 mins read. This post answers a question that I was struggling to find the right answer. If there is one post that you should read this week then It should be this one. From the post:
> A tolerance for failure requires an intolerance for incompetence. A willingness to experiment requires rigorous discipline. Psychological safety requires comfort with brutal candor. Collaboration must be balanced with a individual accountability. And flatness requires strong leadership. Innovative cultures are paradoxical. Unless the tensions created by this paradox are carefully managed, attempts to create an innovative culture will fail.
When AWS Autoscale Doesn’t: 15 mins read. This post by folks at Segment share valuable lessons on AWS autoscaling. The key points for me in the post are:
- AWS autoscaling for ECS follows the formula
new_task_count = current_task_count * ( actual_metric_value / target_metric_value ). The ratio
actual_metric_value/target_metric_value limit the magnitude of scale out event. To overcome this, you either have to reduce the target value leading to over scale all the time or use custom CloudWatch metric
- The default cool down time for scale out event is 3 minutes and cooldown for scale in event is 5 minutes
- Multiply your time by asking 4 questions about the stuff on your to-do list: 10 mins read. This post won’t tell you how to magically make each day 38 hours long (we’re still working on that). But by assessing our tasks in terms of their significance, we can free up more time tomorrow.
Dotfile madness: 10 mins read. I just counted my home directory has more than 30 hidden directories. The post makes a valid argument against proliferation of dot files and dot directories. The author writes:
> Avoid creating files or directories of any kind in your user’s $HOME directory in order to store your configuration or data. This practice is bizarre at best and it is time to end it. I am sorry to say that many (if not most) programs are guilty of doing this while there are significantly better places that can be used for storing per-user program data.
Life of a SQL query: 15 mins read. What happens when you run a SQL statement? We follow a Postgres query transformation by transformation as a query is processed and results are returned.
Splitting Up a Codebase into Microservices and Artifacts: 10 mins read. This is the first post that you should read if you are thinking about Microservices. I like the way this post first talked about using module boundary to split the code base. If module boundaries are not enough then you should think about Microservices. In my opinion, you should choose Microservices 1) to scale engineering organization 2) the real need for your polyglot environment depending on your business problem.
Golang Datastructures: Trees: 20 mins read. This is an awesome read even if you can’t comprehend Golang. This beautifully written post explains how to implement a simple DOM tree in Golang. It shows implementation of breadth first search and depth first search algorithms to implement find functionality. I thoroughly enjoyed this post.
Deploying Python ML Models with Flask, Docker and Kubernetes: 30 mins read. This is an extensive tutorial that shows how to deploy Python Flask applications on Kubernetes. It covers how to deploy Machine Learning (ML) models into production environments by exposing them as RESTful API Microservices hosted from within Docker containers, that are in-turn deployed to a cloud environment.
A Minimalistic Guide to Kata Containers: 5 mins read. This is a short post that I wrote about Kata Containers. Kata Containers provide the best of containers and virtual machines. Read the post to learn more.
Building a Better Profanity Detection Library with scikit-learn: 15 mins read. This post covers how you can write your own profanity filter using machine learning. The author starts by giving reasons why he didn’t use existing profanity libraries and then he goes over the steps required to create your own profanity detection library.
The time to read this newsletter is 155 minutes.
I read a book one day and my whole life was changed – Orhan Pamuk
Continue reading “Issue #24: 10 Reads, A Handcrafted Weekly Newsletter For Software Developers”
The time to read this newsletter is 165 minutes.
If we encounter a man of rare intellect, we should ask him what books he reads. – Ralph Waldo Emerson
Continue reading “Issue #23: 10 Reads, A Handcrafted Weekly Newsletter For Software Developers”
The time to read this newsletter is 150 minutes.
Curiosity is, in great and generous minds, the first passion and the last – Samuel Johnson
- Monorepos: Please don’t!: 20 mins read. In this post, Matt Klein gives reasons to why monorepo approach does not provide benefits most often cited by monorepo proponents. His recommendation is to go with polyrepo structure. The post makes four valid arguments:
- Organizations that use monorepo spend considerable engineering resources on building tools to work with monorepos. Most organisations don’t have such luxury.
- Monorepo makes it difficult to open source internal projects as you have single commit history
- Most VCS are not meant to be used for large monolithic repositories. There is some work done by Microsoft as part of its git VFS project but it has some rough edges.
- The last interesting point that post makes is The frank reality is that, at scale, how well an organization does with code sharing, collaboration, tight coupling, etc. is a direct result of engineering culture and leadership, and has nothing to do with whether a monorepo or a polyrepo is used.
The main drawback of polyrepo approach is that it creates a culture where different teams own different parts of the code. There are few people in organization aware of the big picture. This point is beautifully put by Adam Jacob in his post – Monorepo: please do!.
My take on this is somewhere in between. For example, if you are building a web application then I like to keep all backend Microservices in one repository and front-end application in another repo. I think the best is somewhere in between the both approaches. Taking either too far does not work.
Continue reading “Issue #22: 10 Reads, A Handcrafted Weekly Newsletter For Humans”
The time to read this newsletter is 165 minutes.
He who learns but does not think, is lost! He who thinks but does not learn is in great danger — Confucius
- Stop Learning Frameworks: 15 mins read. This post makes a great point that we should focus more on gaining deep understanding of software development fundamentals than learning new frameworks. Frameworks come and go and most of the time knowledge you gain is not portable. Focussing on core software development topics like algorithms, unit testing, design patterns, HTTP, DDD, etc will give you better return for your time. If you encounter a new technology at work then you will learn it anyhow.
Another post on similar lines that I read this week said Stack is irrelevant. Author writes,
I’ve started with almost no knowledge about the stack and been up to speed in less than 3 months or so. This is why I always tell people to pick up technology and language agnostic problem solving skills because those are the only skills transferable across stacks.
- Analyzing Hacker News book suggestions in Python: 15 mins read. A quick tutorial that will teach you how to do simple text processing in Python. This tutorial covers how to find top book recommendations in an HN thread. The approach used in simple and most programmers can easily follow it.
- The Major Features in Postgres 11: 20 mins read. This is 24 page PDF slidedeck covering important features introduced in Postgres 11. My favourite features from the list are:
- Partitioning table by hash
- Parallel hash joins
- Finer-Grained access control
- Materialized views vs. Rollup tables in Postgres: 15 mins read. I loved this post for being clear and to the point. It teaches when to use Materialized view and rollup tables. I could see myself using it in near future. Great post!
- How to Get Over Productivity Guilt: 10 mins read. Just the kind of post that you need to end your year. I feel productivity guilt on many days. I am trying to be better at it. Else, it kills all your happiness and you end up doing nothing. Prioritize the essentials tasks that you need to do and get them done. Life will be good. Don’t over stress yourself.
- The business case for serverless: 10 mins read. I spent few months on building an application using Serverless. I uses AWS stack to build the application.I enjoyed Serverless experience but I found that pace of development goes down as you are not able to do end-to-end testing on your local machine. This post does a good job in making a business case for Serverless. The main point author makes is that Serverless increases developer velocity. Author concludes the post by writing
One day, complexity will grow past a breaking point and development velocity will begin to decline irreversibly, and so the ultimate job of the founder is to push that day off as long as humanly possible. The best way to do that is to keep your ball of mud to the minimum possible size— serverless is the most powerful tool ever developed to do exactly that.
Another interesting post on Serverless that I read this week is by Amazon ‘s Tim Bray — Serverless Everything. He proposed an interesting way to look at Serverless using data plane and control plane analogy. Give it a read, it is not that long.
The Amazon MQ service, which is a managed version of the excellent Apache ActiveMQ open-source message broker. To make this usable by AWS customers, we had to write a bunch of software to create, deploy, configure, start, stop, and delete message brokers. In this sort of scenario, ActiveMQ itself is called the “data plane” and the management software we wrote is called the “control plane”. The control plane’s APIs are RESTful and, in Amazon MQ, its implementation is entirely serverless, based on Lambda, API Gateway, and DynamoDB.
- Benchmark PostgreSQL With Linux HugePages: 15 mins read. PostgreSQL is my first choice when it comes to RDBMS. This post covers how we can configure Linux HugePages configuration to improve performance of Postgres database. Author concludes the post by writing
One of my key recommendations is that we must keep Transparent HugePages off. You will see the biggest performance gains when the database fits into the shared buffer with HugePages enabled. Deciding on the size of huge page to use requires a bit of trial and error, but this can potentially lead to a significant TPS gain where the database size is large but remains small enough to fit in the shared buffer.
- How we built Globoplay’s API Gateway using GraphQL: 15 mins read. This blog start with the reason why Globo’s team decided to use GraphQL instead of REST for building API. The main reason outlined in the post for choosing GraphQL is the ease with which you can support different requirements for different devices. After covering the why GraphQL, the post talks about how you can get started with it.
In mid 2018, we had two backends for frontends (BFF) doing very similar tasks: One for web, and another for iOS, android and TV. As much as I love the “backend for frontend” idea (and how cool it sounds), we could not keep the current architecture. Not only because of the reasons I just said, but because each BFF was serving slightly different content to its clients while the business team started to ask for something new: Ubiquity among all clients. the more I reviewed everything we needed to support, the more GraphQL started to make sense. While TVs need a big program poster, mobiles need a small one. We need to show exactly the same video duration among all clients. TVs should provide detailed information about each program, but iOS and android could show only a poster + program title.
- Envoy Proxy at Reddit: 20 mins read. The post goes into depth on why Reddit moved to Envoy for service to service communication. What I like in this post is how they incorporated a new technology in a step by step manner rather than going the Big Bang approach. It is a well written post so you will end up learning a lot about how big sites like Reddit introduce new technologies in their ecosystem and how they architecture evolve over time. The post outlines three requirements Reddit team had from their service mesh choice. Envoy and its ecosystem fit all of these requirements.
- Performance: Avoid adding a performance bottleneck at all costs. Any performance losses at the proxy level need to be offset by considerable feature gains. The two biggest considerations here were resource utilization and latency impact. Our mesh approach accounts for a sidecar proxy on every host, so we wanted the solution to be one that we were comfortable running on every host and at every hop in the network.
- Features: The biggest differentiator among the options was the possibility of L7 Thrift support in the proxy. Thrift is our main inter-service RPC protocol and without first-class support for the behavior control we want in a service mesh, it wouldn’t make sense to switch to something that would just be providing the same basic TCP load balancing we’re getting out of HAProxy. We’ll address this in the next section.
- Integrations and Extensibility: Being able to contribute or request integrations and possibly extend out-of-the-box functionality was also a core requirement. The network proxy needed to be able to evolve with Reddit’s service needs and developer feature requests.
- Going Head-to-Head: Scylla vs Amazon DynamoDB: 30 mins read. This post compares ScyllaDB with Amazon DynamoDB. Author writes, Scylla is a drop-in replacement for Cassandra, implemented from scratch in C++. Cassandra itself was a reimplementation of concepts from the Dynamo paper. So, in a way, Scylla is the “granddaughter” of Dynamo. That means this is a family fight, where a younger generation rises to challenge an older one. It was inevitable for us to compare ourselves against our “grandfather,” and perfectly in keeping with the traditions of Greek mythology behind our name.
The conclusion from the post says it all
- DynamoDB failed to achieve the required SLA multiple times, especially during the population phase.
- DynamoDB has 3x-4x the latency of Scylla, even under ideal conditions
- DynamoDB is 7x more expensive than Scylla
- Dynamo was extremely inefficient in a real-life Zipfian distribution. You’d have to buy 3x your capacity, making it 20x more expensive than Scylla
- Scylla demonstrated up to 20x better throughput in the hot-partition test with better latency numbers
- Last but not least, Scylla provides you freedom of choice with no cloud vendor lock-in (as Scylla can be run on various cloud vendors, or even on-premises).
I will end this newsletter with a short video — The Electronic Coach. This short video shows how Donald Knuth build a mainframe program that helped a basketball team win 11 out of 14 matches. This is an early example of computer used in data driven decision making. In case you don’t know Donald Knuth, he is one of the greatest computer scientist. His book The Art of Computer Programming is included by American Scientist on its list of books that shaped the last century of science.
The total estimated time to read this newsletter is 190 minutes.
The secret of getting ahead is to get started – Mark Twain
- Facial recognition: It’s time for action: 30 mins read. This is a post by Microsoft on the need for government regulation and responsible industry measures to address advancing facial recognition technology. This is a welcome step by Microsoft and it shows them that they are on the right side of the issue. The post lays out the potential dangers of facial recognition if it is not regulated. The three main problems outlined in the post are:
- Certain uses of facial recognition increase the risk of decisions, and, more generally, outcomes that are biased and, in some case, in violation of laws prohibiting discrimination
- Intrusion into people’s privacy
- The use of facial recognition technology by a government for mass surveillance can encroach on democratic freedoms
Microsoft has also defined six principles that they are adopting to address the concerns. These are 1) Fairness 2) Transparency 3) Accountability 4) Non-discrimination 5) Notice and consent 6) Lawful surveillance.
- Why You Should Never, Ever Use Quora: 15 mins read. I personally don’t use Quora for last many years. I find it full of gossip and useless questions and answers. The author makes a good point about Quora lack of intent to make knowledge accessible. Quora does not provide any API or data export tool. They have explicitly forbidden Internet Archive from indexing their web site. Also, you will be forced to login before you can see full answer text. Moreover, they are having trouble making money. So, you never know if they will exist few years down the line. This makes it even more important that they allow shareability of their data.
- The Swiss Army Knife of Hashmaps: 30 mins read. This post covers new implementation of HashMap based called Hashbrown. Hashbrown is based on Google’s SwissTable implementation. The blog starts from HashMap basics covering hashes and different implementations of HashMap using linear probing, Robin Hood hashing, and finally talking about Hashbrown. This post gives you a good understanding of HashMap.
- Why you need both rituals and routines to power your workday: 10 mins read. The post covers the importance of routines and rituals to make most of the day. Routine is a series of regularly followed actions. Rituals, on the other hand, are those symbolic actions performed at key moments that help us move through the day smoothly.
- How Pinterest runs Kafka at scale: 10 mins read. This post talks about how Pinterest is using Kafka. Pintrest has one of the largest Kafka deployments in the cloud. Their Kafka deployments runs in three AWS regions. They make use of MirrorMaker to transport data among three regions. They created and open sourced DoctorKafka, a Kafka operations automation service to perform partition reassignment during broker failure for operation automation. They use d2.2xlarge instances for brokers.
Using Golang to Build Microservices at The Economist: A Retrospective: 20 mins read. This article by Economist engineer covers in depth why they chose Golang for building their new content platform. The three main reasons outlined in the post are:
- Go has key design elements required for building distributed systems
- Go’s concurrency model is relatively easy to implement
- It is easy too get started and fun to write
- Serverless Tip: Don’t overpay when waiting on remote API calls: 15 mins read. I consider as good software developer, you should not shy away from validating your assumptions. This post goes in depth on how the author did detailed analysis to validate his hypothesis. Author writes, My hypothesis was that by lowering the memory configuration, that the execution of the Lambda function would be slower and perhaps not as cost effective. He then carried out experiments to validate his hypothesis. As it turns out, functions that make remote API calls can be broken down into small, asynchronous components with low memory settings. We get the same performance and significantly reduce our costs, especially at scale.
Our learnings from adopting GraphQL: 20 mins read.In this post, Netflix Marketing Technology team shares their learning in adopting GraphQL. Author writes, We have been running GraphQL on NodeJS for about 6 months, and it has proven to significantly increase our development velocity and overall page load performance.
How To Build A Real-Time App With GraphQL Subscriptions On Postgres: 30 mins read. This is a tutorial to build a real time pooling app. Author does a good job explaining why GraphQL is a good choice for building real time apps. You can use this tutorial to build your firsts GraphQL app.
Your Intuition Is Wrong, Unless These 3 Conditions Are Met: 10 mins read. Daniel Kahneman, author of Thinking Fast and Slow explains why most intuitions are wrong. I loved how he compared two definitions of intuitions and explained why the second is better than the first. The first definition is Intuition is defined as knowing without knowing how you know. The second definition is intuition is thinking that you know without knowing why you do.
Bonus: I will end this week newsletter with a great talk on decision making.
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
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.
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.
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.
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.
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.
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:
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.
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.”
Most of your design choices will be driven by what your product does and who is using it.
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.
Then think about ways to automate, spend your time coding and destroying, and use third parties where it makes sense.
- Don’t scale but always think, code, and plan for scaling.
- 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.
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.
An important requirement for the new application was that there should be no device or operating system lock-in
Needs to operate well under uncertain networking conditions. Hence, offline support is very important
We decided to use TypeScript instead of Flow
For state persistence, we use redux combined with redux-persist for offline support
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.
Any argument about syntax, we defer to Prettier.
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.
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.”.