Publish

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", () => {

The vary header is a response header used to create different variations of an object in the cache. In this post I will show how the vary header works, how we can use it and more importantly ways not to use the header.

How the vary header works

The most widely used use case for the vary header is to vary by the Accept-Encoding header. In this use case, the response returned would be different depending on what Content-Encoding the browser can support. In this case the response header sent by the origin would look something like the following:

vary: Accept-Encoding

To generate the response, the cache will compare the Accept-Encoding request header value with the content-encoding returned by the origin

# request header:
Accept-Encoding: gzip, deflate

# response header:
content-encoding: gzip

In this case we can see the browser supports gzip and the resource stored in cache is of type gzip so we are able to return this without further processing.

Where the vary header does not work well

Issues with caches supporting the vary header come from more advanced use-cases. Here’s an example where we cache variations on the Accept-Language header on top of the previous Accept-Encoding header.

vary: Accept-Language Accept-Encoding

This would allow us to serve different versions to say English and French speakers based on what their Accept-Language header is:

Accept-Language: en
Accept-Language: fr

The problems come from the fact there are many different ways of browsers saying the same thing. All of the below examples are where English should be returned:

en
en-us
en-US,en;q=0.5
en-US
en-US,en;q=0.8
en-US;q=0.8,en;q=0.6,fr-CA,fr;q=0.4

The last one is an example of one where the user speaks both English and

I used to be against Friday deploys. We all know the memes and wisdom that tell us how Friday deploys are a bad thing. I never really stopped to consider otherwise. On a basic level having a deploy freeze on a Friday makes sense for a number of reasons. One thing is we don’t want to be stuck working all Friday evening or all weekend if things go bad. Its easier to justify working a weekday evening than a Friday evening where many have other plans. Another reason is we’re highly likely to have mentally checked out, especially late in the evening, on a Friday. This causes us to rush out things without properly checking them and giving a once over which causes more issues. The superstitious side of me remembers the few Friday deploys I did which went wrong for one reason or another and justifies that as to never deploy on Fridays.

But is this thinking right? Back when deploys were big events and required lots of manual interventions and monitoring it did make sense but the core idea of modern software engineering and devops is to make deploys a non event. Continuous deployment and the pipelines that come with should take care of making sure a change works as expected so we should have full confidence in our deploys.

FRIDAY DEPLOY FREEZES ARE EXACTLY LIKE MURDERING PUPPIES

This piece by Charity Majors helped shift my thinking on Friday deploys. Ignore the extreme headline for a minute and just read the piece. It goes into the many

Resource quotas in GKE managed clusters are hard limits for the number of resources that can be created in a namespace. For a lot of cases you may not run into issues but the quotas are set low enough by default they may be run into for a cluster with more workloads. The quotas increase as you add more nodes to the cluster but for clusters with aggressive scale to zero or lots of small pods this increase may not happen. In this, we will go through how to increase or even remove the quotas from the cluster.

How to see the resource quotas

There is a resourcequota resource created in each namespace when you create the cluster. The default limits are:

• ingresses.extensions: 100
• ingresses.networking.k8s.io: 100
• jobs.batch: 5k
• pods: 1500
• services: 500 You can use kubectl to see the resourcequota for a particular namespace:

$ kubectl get resourcequotas
NAME                  AGE   REQUEST                                                                                        

I’ve read this piece recently by Casey Cobb about how we can use the Pareto Principle in software engineering. The Pareto Principle, or the 80/20 principle, is how for example 80% of car accidents are caused by 20% of drivers. In this piece Casey goes into how we can use this knowledge in software engineering to ship code faster.

https://projectricochet.com/blog/software-development-pareto-principle-and-80-solution

Applying the Pareto Principle to software then the following must be true:

• 80% of features are covered by 20% of the codebase
• 80% of complexity is in 20% of the codebase
• 80% of engineering time is spent on 20% of the codebase
• 80% of customers only care about 20% of the features

The key idea of the piece is that if all of the above are true then we should be able to develop 80% of the application in 20% of the time.

The Bad

My initial reaction to it was that it is a way over-simplification of software engineering. It’s not as easy as just stripping out 20% of the code so everything becomes much quicker. For example the deployment process may take time to set up and configure along with other plumbing which is required for the app to run but cannot just be removed. Similarly auth and using external APIs often takes time depending on how good the docs are but those can be core to the use of the entire app, not just sole features.

The Good

However after thinking about it some more I think the core idea of the piece is sound once proper communication

Book: The Software Craftsman: Professionalism, Pragmatism, Pride Author: Sandro Mancuso

At the title of the book says, we should treat coding as a craft rather than just another job. We should be deliberate about the code we write but also about everything in our careers from the companies we work for, the learning we do right to the time we should search for a new job. So many people, not just software engineers, go through life without fully considering these decisions ahead of time. This book aims to make you realise we should be deliberate about everything we do.

This book is mainly concerned with the general concepts of the craft rather than getting into the nitty gritty of technical details. I feel a lot of what the book has to say has become fairly common knowledge across the industry but it is still no harm to hear it said out loud. For example, he considers QA as a waste of time due to the use of unit testing should leave no surprises at the end.

Two key ideas of the book focus around software craftsmanship and continuous learning so I will outline those below

Software Craftsmanship

Software Craftsmanship is about professionalism in software development.

This is about mindset as much as anything else. Instead of treating writing code as just another job we should be deliberate about the decisions we make and follow best practices. Well crafted software does not only just work. It should be easy to understand and maintain. What it does should be predictable

Go seemingly anywhere in Amsterdam or more widely in the Netherlands and you’ll find it that seemingly everyone cycles. Certainly more than most other western nations. But why is this so?

Weather and landscape play a factor. Having nice weather, basically just not raining, and flat roads to cycle on do play major roles but I think the more important one is that the infrastructure is there. Look around and you see segregated cycle lanes that don’t just end randomly like they do many other cities. They’ve even built an underwater bike shed instead of leaving it up to you to find somewhere to put your bike like many other cities.

Socially too it is accepted or even expected to cycle.

So why is this so. If you went back to the post World War 2 days of the 50s and 60s you’d probably find the popularity of cars rising at the same rate as most other western European nations. Oil was cheap and the car was the ultimate expression of freedom. The continent was rebuilding and the economies were growing rapidly.

This all began to change in the early 1970s with a series of major oil shocks. Over the decade the price of a barrel of oil rose from about 3 dollars to about 12 dollars, a 300% increase. For comparison, today the price of oil sits around 80 dollars. A similar increase would move it to 240 dollars. Nowadays we are somewhat used to oil prices fluctuating daily but back then in the post World War years they