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

1. The Bullshit Web: 20 mins read. This post by Nick Heer goes into detail on how we are slowing down the web experience of our users by mindlessly adding third party JavaScript. Nick talks about three aspects of bullshit web – 1) use of surveillance scripts to track user behaviour  2) solutions like Google’s AMP are not the right answer as they are driven by one organization self interests 3) The cumulative effect of all this on the entire web. The web is not as open and secure as it seems. One another reason for the bullshit web is that we have become too much data driven. Being data-driven is not bad, it is the excess of being data-driven that is bad. I think our obsession with third party tracking tool is similar to our obsession with social media. When we see numbers going up, dopamine rises and we feel good. This is just not for individuals but for organisations as well.
2. CAP Theorem for Application Developers: 10 mins read. This is the second post in my distributed system series. In this post, we look at CAP theorem. CAP theorem states that in a distributed data store system we can be either consistent or available in case of network partition. The understanding of the CAP theorem help us figure out which data store will serve our needs better. Usually for write heavy systems, Availability and Partition Tolerance is a good fit. In read heavy systems, Consistency and Partition Tolerance is a good fit. One thing you have to understand is that consistency and availability are continuous rather than binary.
3. In Pursuit of Production Minimalism: 15 mins read. This post by Brandur Leach, engineer at Stripe talks about how you should keep your production system simple by practicing minimalism. He gives six tips – 1) Retire old technology. In our project, after every release (every quarter) we upgrade all dependencies to latest versions 2) Build common service convention i.e. standardised core tech stack of your organization like database, queue server, cache, etc. 3) Favor simplicity and reduce moving parts 4) Don’t use new technology the day, or even the year, that it’s initially released 5) Avoid custom technology 6) Use services provided by your cloud provider rather than creating custom ones.
4. I’m a very slow thinker: 5 mins read. I like this post because there are times I also feel the same. There are times I don’t have answers or I don’t have anything to add to a discussion. I fear this makes me sound stupid. But as author shared, there is no issue with being a slow thinker. You can take your time and think about the problem clearly without any pressure. This way you can look at the problem from multiple view points and probably provide a fresh view point.
5. The art of stealing: 45 minutes read: I will just say read it. It is a long read but worth every minute. It is the story of tragic fate of the masterpieces stolen from Rotterdam.
6. How to Do. One. Thing. At. A. Time: 25 mins read. I know most of us think we know the mantra “Do one thing, and do it well”. But, I fail to apply it most of the time. I get distracted too often. I am trying few things like Pomodoro technique and not using email and slack during off hours to improve my focus. I think all of us need to understand the problem and start taking corrective measure else we are all moving towards unhappy, unsatisfied future. In this post, author Aytekin Tank, founder of JotForm talks about importance of doing one thing at a time. For me the key point was that as a founder Aytekin understands and advocates clean separation between work and family time. If you see your leader doing the right thing then employees also follow the same. Sadly, there are not many organisations that are run by such leaders. Most leaders I have seen are unfocussed, boost about their business, and try to grow in all directions and failing in all of them.
7. Filter Before You Parse: Faster Analytics on Raw Data with Sparser: 15 mins read. Stanford PhD students have released a research project that can speed up JSON parsing. The basic idea behind SParser is that most of the time you only need part of the JSON for your use case. In most traditional JSON parsers like Jackson you end up parsing the full JSON even when you only need part of it. The Stanford guys have built a set of filters that filter out the bytes that you don’t need so that you parse the minimal JSON required for your use case. This leads to big performance boost for big data use cases where you are working with 100’s of GBs of raw JSON data. I think it is also useful when you are consuming REST API JSON responses where you need part of the result set.
8. Digg’s v4 launch: an optimism born of necessity:15 mins read. This is a story of Digg v4 disaster. The proximate cause for Digg’s demise was Google. A shift in Google’s search algorithm drove a lot less traffic to Digg, which meant Digg went from having a lot of revenue to not having a lot of revenue. This pushed Digg to change their monetization strategy. In response, Digg v4 added a social network layer to Digg. The idea is by becoming a social network like Facebook and Twitter, they wouldn’t need to rely on poorly performing SEO driven ad units. The problem was Digg v4 was 2 years late and Digg was running out of money. They gambled. The decision was made to release Digg v4 early, before the money ran out, so they could see if it would bring Digg back from the grave. The problem was it wasn’t close to ready.
9. A Tale of Two Teams: 30 mins read. This is a great read on how you can leverage Serverless technology to bootstrap your startup. I think the main message was how you can you build your startup without getting money from investors. You can do a lot with free cloud services rather than setting up your own tech stack. I loved this story and this story has many things to learn from.
10. E-Commerce at Scale: Inside Shopify’s Tech Stack: 15 mins read. This is a good read to understand tech stack of Shopify. It is high level and they don’t get deeper into why they choose certain technologies. Shopify is a Ruby on Rails monolith and uses MySQL, Redis, Memcached. They run in Google Cloud and uses their Kubernetes offering.  The key point was they run multiple copies of Shopify called Pods. A pod is a fully isolated instance of Shopify with its own datastores like MySQL, Redis, memcached. A pod can be spawned in any region. This approach has helped us eliminate global outages. As of today, we have more than a hundred pods, and since moving to this architecture we haven’t had any major outages that affected all of Shopify. An outage today only affects a single pod or region.