Sounds a bit like an excuse making process to me but according to JP Morgan via the Financial Times today, the green transition away from fossil fuels to renewable energy is going to take decades or generations so we shouldn’t get our hopes up. They cite things like the way places like Scotland set ambitious goals to reduce emissions by 75% by 2030 but have already given up. So according to them we should just let the natural process take its place and not worry too much about this being done anytime soon.

But I disagree. We could make this transition last a lot shorter than that. I think the is down to countries not really wanting to make this transition in the first place. It sounds like they’re just making excuses as to why its all been so slow in the first place. Most renewables take capital to start but are much cheaper in the long run so they payoff is there, it just takes a while for them to come around. So if we could see the full price of keeping coal power plants or diesel cars around we’d see how the full price isn’t that much at all but rather would offer much better returns. Especially to society at large the payoff longer term is much more than monetary terms alone. You’ve the large obvious things like EVs and renewable energy, but there’s also other things like improved cycling infrastructure that have whole other benefits that aren’t easily measured in a price tag

This is some findings from some google research into quality of software. They developed a theory of software quality which involved four types of quality which influence each other. The first two, process and code, are what developers usually think first about software quality. They focus on the health of the codebase and the engineering systems around it. The second two, system and product, are higher level metrics focused in on by executives and product managers.

To make use of this research and improve the software quality of a system, first decide what kind of quality you want to improve

Process Quality

These are the processes around development. So things like planning, testing and code reviews. Metrics focusing on these processes are good predictors of overall software quality.

Code Quality

Maintainability. How easy is it to make changes to the code. That is the main aspect of code quality. So here focus on ease of understanding the code and making sure that one change doesn’t require lots of other small changes.

This affects system and product quality the most as if it’s easy to make changes then you can fix defects much more easily.

System Quality

This involves the reliability, performance and defect rates of the system. It’s difficult to know if these are improving as the only way for an executive to measure it is to see how many outages the system has. If there hasn’t been many then it’s hard to know if there is a bigger or smaller risk of outages. For this reason, code quality metrics are

I’ve been using the golang chi router in one of my projects recently and for the most part it’s been great. I’ve just a simple router with a few routes so I’ve not pushed it to any advanced use cases but it seems simple enough and extensible enough it should get a long way there.

The latest project I’ve needed to do was add Authentication using JWT to two routes. This seemed simple and straightforward as they provide a default JWT middleware implementation called github.com/go-chi/jwtauth. It’s simple and straightforward so easy to get going and I was able to get it working accepting a single token relatively easily.

However as I said above, I needed to accept multiple tokens. Maybe the library could be modified in some way to accept multiple tokens but it doesn’t make it easy and to me did not look possible for the work it would require. This is especially unfortunate as there is a thing in JSON Web land called JSON Web Key Sets which allow you to accept multiple tokens. There is a PR to accept JWK Sets but this has had no activity lately so it’s not clear if it’ll happen any time soon: https://github.com/go-chi/jwtauth/pull/71

Instead in the end I created my own middleware to read a JWK Set using the same underlying library as jwtauth: github.com/lestrrat-go/jwx. As I said above, chi makes it easy to create middleware and the lestrrat-go library makes it easy to accept JWT Sets.

This can be done in a two step process. The first is to parse

I broke my phone a few days ago and it’s in getting repaired. However I can say that the days I’ve been without my phone have been great. I haven’t had to do anything with it and I’ve been just not looking at the screen all day. Sure there’s been trouble especially when I got logged out of work stuff that required 2fa but for the vast majority it’s much better than having a phone. Even just when first waking up or on lunch I don’t need to be looking at a phone the whole time there.

I tried looking up to see if I could make a feature phone work but I don’t think so. Really the only things I need a phone for are mostly the apps on it so buying one of those probably wouldn’t work at all. There’s also other “dumb” phones that try fill this niche like lite phone but those are very expensive for what it is.

In the end however I need to improve how I use my phone and control when I use it. Make sure I’m using it as a tool rather than reaching for it day to day when I get bored or uncomfortable. The same for simple times like eating lunch or whatever, instead of carrying it around all day just don’t bother bringing it and embrace the boredom a bit. Just do nothing instead.

JSON Web Keys are what is used to generate and verify JSON Web Tokens. Here I will explain how best to rotate JWKs.

If you’re coming from zero like me and building something that uses JWT to verify a request is what it should be then the first thing you’ll do is use a JWK to verify a JWT. Using the github.com/lestrrat-go/jwx library in go it can be done like this:

parsedKey, err := jwk.ParseKey(key)
parsedToken, err := jwt.ParseString(token, jwt.WithKey(jwa.HS256, parsedKey))

However now any time you change the key you’re going to run into problems where it will be a hard break. So now the old token will stop working straight away and the new token will be accepted without any overlap period between. This is a problem for APIs as now you’re going to have a whole load of failed requests before you can get the new token to each of them. Sure this may be okay if you think you can roll it out quickly enough or you can add some extra code to the clients but this extra complexity is not really what we want.

Instead it’s better to use JSON Web Key Sets (JWK Sets) which are arrays of JWKs like the example below. You can see we have two keys with different key (k) and key ID (kid) values to differentiate them. Any keys in the set will be accepted so now when you are rolling a token, you can just update the set to have both the new and old JWKs. Once you’re finished updating

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 = personal@mutablecomment.com

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

The .gitconfig-work file will look like this:

[user]
    name = Mutable Comment
    email = work@mutablecomment.com

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/