Useful Stuff I Read This Week

Here are 11 posts I thought were worth sharing this week.

I like the idea of learning a new language by reading its standard library. You learn the idiomatic way of writing code in a language by reading source code written by its original authors. I am planning to learn Rust. I will also give this approach a try. There are two limiting factors when you might struggle with this approach 1) Poor documentation 2) when the standard library is implemented in a lower level language.  

Author of the post shares his views on important features he expects from a future scripting language. I agree with his list. I will add a couple more:

  • Better tooling support. Author talked about IDE but I think tools for formatting, packaging, scaffolding, new modules, etc should also be part of the language standard tooling. 
  • Simple. It should have one idiomatic way to do a task. Also, stability should be preferred over feature bloat. 

I enjoyed reading this post. If you are Redis you should definitely give it a read. The post covers multiple Redis use cases apart from caching. Redis has three features to enable event-driven reactive architectures – Pub/Sub, Keyspace notifications, and Streams. I am aware of Pub/Sub and Streams but I was not aware of Keyspace notifications. The post also covers how you can schedule events in future using TTL and shadow keys. 

Nice post on time series database. You will learn a lot about time series databases by reading this post. 

  • Time series databases are write heavy. They are mostly inserts. Rarely there are updates. Typically 10:1 write to read ration
  • Time series databases are distributed by design and compresses data on disk to support large datasets
  • Read queries touch most of the data so caching does not help
  • ACID is not a strict requirement
  • Their query language need to support aggregate functions, ordering, ranking, and limiting
  • They should support visualization and graphs

I have been in the “Learned Helplessness” situation and I can tell you it is not beneficial to anyone. You learn to ignore the problems, stop speaking on important issues, and finally move on. Most often you can’t change the organization’s way of working. People will even say they want to change but the system always wins. This post is essential reading for all engineering teams and their managers. The post covers the patterns and how you can take corrective actions to change the situation. 

This is a must read if you too are thinking about giving AI enabled code generators like Github Copilot a try. Authors ask interesting questions that we should ask when we use such tools:

  • Is the generated code performant?
  • Is the generated code readable? Can we treat generated code like compiler output?
  • What will happen when Copilot will be trained on code it has generated? 

There are a couple of questions that I had as well:

  • Will tools like Copilot be a disadvantage to non-native English speaking developers? Many developers struggle to communicate their problems in English.
  • Will developers own the auto-generated code? Typically generated code is in a different source folder and teams don’t do code review for the generated code. Now, with tools like Copilot generated code and the code you are writing is in the same file. I am not sure if developers will own the code when things go wrong.

This is an interesting space. All of us want to become more productive. But, we don’t want dumb developers as well. 

This is a short(~ 6 mins) video. In this talk, Simon Peyton Jones, major contributor to Haskell programming language talks about a 2×2 programming language decision matrix.  On one axis  is Useful/Useless and on the second axis is the Safe/Unsafe nature of the language.

This is a loooong read. It covers many less known useful features of Postgres. I have bookmarked this link and will refer to it when I am using Postgres. My favorite features from the list are:

  • Grant Permissions on Specific Columns
  • Match Against Multiple Patterns
  • Prevent Setting the Value of an Auto Generated Key
  • Two More Ways to Produce a Pivot Table
  • Keep a Separate History File Per Database
  • Generate UUID Without Extensions

This post covers formal methods like TLA+, common verification methods like unit & integration testing, monitoring,etc. and modern testing methods like random model checker, fault injection, canary testing, etc. These days most of us are building distributed systems. These systems have a variety of failure modes that can’t be tested by just unit and integration tests. We need to learn and use modern testing techniques to build fault tolerant systems. 

I am not into games. This is a good overview on main components of a game engine – Math Engine, Rendering Engine, and Physics Engine. It provides a high level overview of each of the component engines and how they interact to deliver game experience. 

I have built my second brain using Evernote. I use the legacy Evernote version. The main reason I built is to clear my head and find relevant information at the right time. Since I use multiple macbooks I rely on Evernote multiple device support for smooth work transition. 

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: