Gerald Weinberg, one of my favorite technical authors, wrote a book titled The Psychology of Computer Programing decades ago, in 1971. This book is timeless because it explains computer programming as a human activity.

I read this book a few years ago. Recently, when I was browsing through my kindle, I stumbled across and reread a few chapters that teach the importance of reading programs and explain what makes a good program. This post is a short, condensed version of those chapters. The language, of course, is a bit dated, but the lessons are timeless.

Enjoy reading!

In the last post in the Turbo Internals series, we saw how to set up the Turbo source code for debugging and development. In this post, let’s dive into the codebase and try to understand the sequence of events that take place when you click a Turbo link.

In Rails, routes map an incoming URL to a controller action. When you define a route for your application, you also get path and URL helpers to build relative or absolute URLs from the route’s name. For example, suppose that you have a users resource in your config/routes.rb:

resources :posts

This route creates the method posts_path that you can use in the view. For simple routes, you can probably guess the output of the helper, e.g., the posts_path helper will return the URL /posts. For complex routes, especially nested ones, it can be hard to figure out the URL until you use the helper to render the view.

This post shows a simple way to check the output of URL and path helpers directly from the Rails console. We will also see how to access these helpers in your models.

Docker builds images using a Dockerfile that contains all the instructions needed to create an image. Each instruction maps to a read-only layer stacked on top of the previous layer and is a delta of the changes from the previous layer.

This caching mechanism improves the performance and efficiency when building images. However, sometimes it can cause unintended issues. This post explains few such cases.

Recently I’ve been reading the source code of the Turbo library. The code is well-written and easy-to-understand. Reading it has been a fun exercise, not just to learn the internals of Turbo, but also how experts like Sam Stephenson write their JavaScript. I took a lot of notes while reading the code, and I will share them in future posts.

This post explains how to download and set up the codebase so you can easily debug and step through it in the browser.

Today at work, I was trying to add tests for an email notification feature I wrote last week. Without going into too much detail, the way it works is that the app should only send the email under certain circumstances. So I wanted to write a test to ensure that the app was not sending an email under those conditions.

I was reading the source of the Turbo library and came across following code in link_click_observer.ts, which executes whenever the session starts (when the page loads) and Turbo starts observing the links and forms:

After deploying web applications for so long using Heroku or other services that automate deployment, I realized that I didn’t really know everything that happens behind the scenes from taking an application from development to production. So I spent a weekend trying to deploy a Rails app to a bare metal server provisioned on AWS. It was a fun experience and I learned a lot. Here’re my notes from the entire process.

An interface is a place where two things meet: the human and the computer. The computer has functions it can perform. The human needs inputs and outputs to take advantage of those functions. The interface is the arrangement of inputs and outputs that enable people to apply the computer’s functions to create outcomes they want - Ryan Singer

Repetitive setup code in tests makes it difficult to refactor the tests. It also distracts and shifts our focus from the business logic that we’re trying to test with the setup details. This post explains three ways to reduce the setup duplication in your tests.