Useful Stuff I Read This Week

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

This post covers how and why Hasura switched their CI service from CircleCI to Buildkite. They started by defining the requirements from their CI, then they evaluated different solutions, and finally introduced it in their ecosystem. Their main reason to switch CI service was cost. They reduced the cost by 50%. This required them to own some of the aspects of the CI operations. A couple of interesting things I learnt from this post:

  • Use of labels to trigger build. They used them to save costs.
  • The use of dynamic configuration. They wrote their build code in a Go program. This saved them from YAML hell. Interestingly, they use shellcheck   t   static analysis of shell script

It is all about perspective. Tech Debt brings negative emotions in people and it becomes difficult to sell it to higher management. In this post, the author suggests we reframe tech debt as tech wealth while communicating with stakeholders. Building tech wealth means getting more value out of the software we’re creating, as well as our efforts to develop and maintain it.  Author suggests two ways we can plan for tech wealth:

  • Allocate time within each planning cycle
  • Dedicate the last few cycles in a quarter

In one of the products I worked on we used to schedule 1 day per sprint (2 weeks) for paying tech debt. We had sprint demo every alternate Thursday and the next day i.e. Friday was scheduled for working on tech debt items. One problem with 1 day every sprint is that bigger items can’t be handled. We used to create stories for them and pick them as part of the sprint backlog.

Loved this post. We all make terrible mistakes. Documenting them and sharing them with a wider audience can help others avoid making the    mistake. The worst mistake that I have made is not making use of database processing capabilities. Instead, I wrote custom logic. A well written SQL query often outperforms custom logic.

I am not using ShapeUp at work but I am following more or less the same philosophy to deliver a complex mobile banking application. We plan backwards starting from a demo we want to do at the end of 5 weeks. We have set constraints on time and scope. Then, we execute weekly with freedom to change approaches, experimentation, cleaning tech debt. To do this, it requires a clear vision that both parties(business and development team) agree on. Then we need a navigator(s) who can ensure the team is moving towards the agreed goal. There is some level of tracking required but not too much.

Sometimes a simple situation is better and more efficient. This article talks about how we can use polling to simplify event sourcing implementation. Most implementations of event sourcing use a message broker like Kafka or RabbitMQ. There are multiple design challenges introduced by adding a message broker in event sourcing system – 1) Atomic transaction between event store and message broker 2) event ordering 3) add new read model. I enjoyed reading this article as it discusses practical problems and gives a simple solution. You will have to understand the tradeoffs of the polling solution before embarking on that journey.

This post covers various ways to profile Python code for performance bottlenecks.  It covers cProfile, py-spy, line_profiler, and py-heat tools.

I loved reading this post. I could relate to it since it happened to me also last year. I gave my old Ipad to my niece and they were unable to play games in the Chrome browser because the Chrome version was too old. The Apple store does not support the first generation of the Ipad so there was no way I could update it to the latest version. Another important point made in the post is that you should keep in mind that there are still devices that do not support modern Javascript so if you ship it directly then your website might not work.

This post takes a step by step approach to defining high availability in the context of Postgres. It covers a couple of solutions that provide high availability. 

I used Vue once in my personal project and I enjoyed it. I found it productive and easy to learn with good documentation and resources available on the web. For me the favorite part of Vue as mentioned in the post is Single File Components can be wonderful to work with because you can encapsulate everything you need right there without a lot of jumping around to many different files.

I loved the simplicity of the idea. It solved a real problem for the author and others connected with it. I also gave it a try. It is a nice tool. I also liked the idea of selling your small business. I might take some inspiration from the author.

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 )

Facebook photo

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

Connecting to %s

%d bloggers like this: