Posts

If retries aren’t randomly distributed over the retry window, a small perturbation (e.g., a network blip) can cause retry ripples to schedule at the same time, which can then amplify themselves

Using exponential backoff is great because if you keep retrying over and over without limits you’re eventually going to break something. Exponential backoff increases this retry period exponentially until you eventually give up. Jitter takes this one step further by adding a random difference between the retries so that if all requests fail at once, they are not all retried together after a short blip. Without jitter you may cause a ripple where all requests are retried at once causing further issues. for example a network being down for 1 second will cause all requests to pile up and be retried at once, then again and again, snowballing until a simple network error causes a wider server outage

https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/ https://sre.google/sre-book/addressing-cascading-failures/

I want to write but I find it so hard to publish. I want to do it because I can see the value out of it. I know a lot of people post how good writing has been for them and part of that is just survivorship bias where someone like myself who reads a lot of these posts is going to come across a lot of writers who make most of their living from writing posts and thus will be more inclined to write about how good writing is. Even then though I can see the value of it, just writing small snippets like these. I’ve written a lot of these things and most are just ramblings around random things with no real value. But if I could somehow focus those to specific topics or even create a separate place for me to write publicly but is easy enough that I’m able to just pick up and publish whatever then maybe I could become better at it over time.

So that’s what this is. Just a load of ramblings around random topics that I’m hoping to build into something over time so that I become better at writing. A lot will be nonsense and a lot will be short but over time maybe I’ll be able to become better at this and create something of at least a little value. Just build a habit and then see what happens.

Characteristics of a good change

Reviews: As a reviewer you should know it’s not going to be a perfect change so don’t focus on it being 100% perfect. This means avoid nitpicking as much as possible. Focus on moving faster and changing things continuously rather than getting it perfect straight away. Instead know the change is just one part of a process and continuously improving the codebase will bring it up to a better standard. Be open to the author’s approach instead of expecting it to be done a certain way.

Comments should be treated as a learning opportunity where you share your knowledge about language features and the codebase. Avoid personal criticism in reviews as it’s easy for some comments to be taken personally.

Comments: Aim for small changes above all else. Prefer a series of smaller changes over one large one all at once. As a rule of thumb each one should be under 200 lines of code. Each change should maintain or improve the health of the codebase

Outcome: Following these guidelines means the majority of changes should be small and only take one reviewer who leaves no comments. The majority (70%) should be committed less than 24h after asking for a review.

Google Critique: one feature of Critique is it provides static analysis tools which provide actionable feedback automatically. This avoids much of the nitpicking comments that hold up many reviews. It also makes obvious who is supposed to be taking the next action

https://read.engineerscodex.com/i/139414745/googles-code-review-guidelines

Background

I have one laptop with both personal and work projects. I have organised code into two folders, work and personal so I want to use a different git identity for each:

• /code/work
• /code/personal

.gitconfig

The basis for the solution here is we can conditionally include other config files in the main .gitconfig file and then create a different .gitconfig file for each identity. For example here is the main file:

[user]
    name = Mutable Comment
    email = [email protected]

[includeIf "gitdir:~/code/work/"]
    path = ~/.gitconfig-work

The .gitconfig-work file will look like this:

[user]
    name = Mutable Comment
    email = [email protected]

This setup allows me to use a different git identity per folder. For this particular setup, the default is my personal account but the /code/work folder will use the work email.

https://garrit.xyz/posts/2023-10-13-organizing-multiple-git-identities

Tips for better error handling in go:

• Wrap the error being returned using %w and fmt.Errorf()
• Avoid words like failed or error - it is an error so we know something went wrong
• Use present tense to describe what the code is trying to do

// good
fmt.Errorf("connecting to db: %w", err)
// bad
fmt.Errorf("could not connect to db: %w", err)

what makes Go’s error handling different is the opportunity it gives the programmer to tell a story. The trick to telling the story right is to add meaningful context to the error wherever possible. In Go, adding error context literally means expanding the message of the error you’ve just received with some explanatory text of what you were doing when the error occurred.

The error type in Go is a simple interface, exposing an Error() method returning a string. So, for practical reasons, all errors in Go can be equated to strings (although you can make them more complex if you want to).

• https://preslav.me/2023/04/14/golang-error-handling-is-a-form-of-storytelling/

I love watching Formula 1. I fell in love with it for the race between engineers as much as the drivers. Both pushing the limits of what can be done within the legal boundaries and outside too without getting caught. But the problem F1 faces in recent years is it has become a victim of its own success. It has become so popular that it cannot put on enough races for the entire calendar. Races draw in crowds of hundreds of thousands with millions more worldwide watching on TV.

With this success Formula 1 has tried to expand the series by adding more races but 25 seems to be about the upper limit it can fit into a calendar year, at least not many more. Dragging the entire circus halfway across the world for a race and then back again the following week eventually catches up to the series. Heritage circuits like those in Europe that draw in massive crowds are becoming under pressure from tracks in the Middle East spending huge money to host Grand Prix with Formula 1 potentially loosing some of the history and appeal as those tracks fall off the calendar. Additionally the number of teams cannot be expanded much more, even though there’s been plenty of parties that have expressed interest in doing so. One more thing that could be improved is the fact some races are plain boring. Even the championship itself is boring some years, with 6 races left this year with the drivers and constructers Championships already decided. Finally

I’ve spent a lot of time thinking about how urban planning has been done and what could be done to make it better. In many ways the technical challenges aren’t all that big, the main problems are the political challenges that are around making any change to the physical environment or peoples behaviour. Even so given that there’s a lot that should be done to fix some of the issues we have. I think there’s a few issues with Galway that are relatively easy to fix if you could magic away the money and political problems. For example, much better public transport and building dense housing within certain corridors would provide needed housing while also allowing them not to require cars. If you planned a light rail system or bus rapid transport system along an east-west corridor and planned dense housing along it you could alleviate many challenges the city is facing

This is the rough idea I had where the red line is the transport corridor and the blue is areas alongside that corridor which are currently underdeveloped. The blue would be a mix of residential, office and commercial spaces with each being their own 5-minute neighbourhood. Currently they are either greenfield spaces or shopping centres where the majority is car parking

Another feature of Galway is the train line which runs to the east of the city. Currently there is one train station which has only a car park around it. There is potential for new stations and developments

A book by Charles Montgomery about how some people are happier in cities than others. A lot of it boils down to what seems like common sense now and generally goes against what the general knowledge of cities were after WW2 and about 2015 when this book was published. This is slowly changing in modern times with planners more focusing on higher density and better public transport

There’s a few central ideas that are throughout the book but generally it can be summarised as suburban low-density car-dependent neighbourhoods are bad for our health and the environment. The book focuses more on the human impact than the environmental one.

However ultra-high density is not something to aim for either. In-between neighbourhoods or what is now known as a 15-minute city. He tells how someone who used to live in a luxury high-rise Vancouver apartment with magnificent views is now much happier that they moved to a terraced home just below the apartment tower they previously lived. The change in happiness could be traced back to the sense of community amongst neighbours.

Car dependence

Although it is not a widely held belief nowadays there is increasing evidence that our car dependence was a bad thing. Cities that are overly dependent on cars produce unhappier unhealthier people in almost every way. Those people often need to commute far longer which means they have less time to spend with their families and this results in weaker family ties. To do anything means driving long distances which in itself is bad for multiple reasons.

What is GORM? It is an ORM built to be used in golang. Previously I was using bun but came across a few issues which proved more complex than they should be so I transitioned to GORM to test out if those would help solve the issues I came across. The resulting code was far smaller but there were some things that proved challenging in GORM.

What is this post about? I have started using GORM recently and came across a few problems with it. This post is a summary of those problems and how I solved them.

This is the model I will be basing my examples on. It is part of a billing system where a Person has a credit card. Since they can only have one credit card it will be a has-one relationship. We are just storing the billing token associated with the card.

type Person struct {  
  ID           int  
  Name         string  
  Email        string  
  CreditCard   CreditCard
  CreditCardID int
  CreatedAt    time.Time  
  DeletedAt    time.Time  
  UpdatedAt    time.Time 
}  
  
type CreditCard struct {  
  ID           int  
  Token        int64

Once you have a worker set up, you probably want to write tests for it. In this guide I will show how to write tests for outbound fetch() requests using vitest and miniflare. Originally I used the following guide to get the tests working but it seems not everything is included within the guide that may be obvious for first time Worker developers.

https://miniflare.dev/testing/vitest

Setup

Install Vitest

$ npm install -D vitest-environment-miniflare vitest

If you are not using service bindings you can use the following vitest.config.ts file:

import { defineConfig } from "vitest/config";

export default defineConfig({
  test: {
    environment: "miniflare",
  },
})

Finally use the following to enable Typescript support and type checking

{
  "compilerOptions": {
    ...
    "types": [
      "@cloudflare/workers-types",
      "vitest-environment-miniflare/globals" // add this line
    ]
  }
}

Minimum Worker Example

To be able to test a worker I had to use either a Service Worker format or have a handle() function that manipulated the request which was then called from the Module Worker. Here is an example worker

export default {
	async fetch(
		request: Request,
	): Promise<Response> {
		return  await handleRequest(request)
	},
};

async function handleRequest(request: Request): Promise<Response> {
	const response =  await fetch(request)
	const newResponse = new Response(response.body, response);
	newResponse.headers.set("x-new-header", "hello world")
	return newResponse
}

This will simply makes a request to what was passed in, adds a new header and then returns the response.

Writing Tests

This can now be tested using the following

import { expect, it } from "vitest";
import { handleRequest } from ".";

const describe = setupMiniflareIsolatedStorage();

describe("Worker", () => {