A struct tag is a special type of comment on a member of a struct. These comments can be inspected by code and runtime to provide additional functionality

• https://www.digitalocean.com/community/tutorials/how-to-use-struct-tags-in-go
• https://pkg.go.dev/reflect#StructTag
• SO with list of known struct tags: https://stackoverflow.com/a/53530943
• https://github.com/golang/go/wiki/Well-known-struct-tags

Example from the DigitalOcean article, showing the example struct tag

type User struct {
	Name string `example:"name"`
}

• transient on a field means it won't be serialized
  • those fields will have their default values when deserialized
• use cases
  • derived or calculated fields
  • non-serializable references
  • fields that do not represent the state of the object
  • sensitive data you don't want to send over the network
• when paired with the final keyword and newing-up (neither baeldung nor geeksforgeeks suggests a use-case for pairing these keywords)
  • if right hand side is a literal, value will be that literal
  • if a e.g. new String(...), value will be null

References​

• transient keyword in Java - GeeksforGeeks
• The transient Keyword in Java | Baeldung

This is something I have to remind myself of annoyingly often.

Many of my notes are thinking out loud about a project. Having a record of the thought process that led to a decision is useful, but sometimes I overdo it in a way that feels like I am documenting the entire process for someone else.

Notes are not an immutable snapshot to be dug up and researched in 100 years; they are a tool to help you think now.

Don't write to make a hypothetical archeologist's job easier: write to make your job easier.

You are the primary audience of your notes. You should write them such that you understand them later. If verbosity helps you, then be verbose, but it's not a goal on its own.

Prompted by seeing the term "barrel imports" in the MUI docs where they suggest avoiding them because they slow down rebuilds during development. (Tree shaking means they have no impact on prod builds.)

Based on a google search for "barrel imports", they are considered an anti-pattern, so it's not solely a MUI problem.

In theory, upgrading to a new version of a package, should be as simple as upgrading the pom.xml with the new version.

In practice, that often is not sufficient. This note covers the workarounds.

[!tldr] You may need to clear the local Maven package cache.

mvn dependency:purge-local-repository -DactTransitively=false -DreResolve=false

This website is sort of an experiment. It is implemented as a blog because blog software provide some useful features, but it has slightly different goals.

You could say it is dissimilar to, yet not entirely unlike¹ a blog.

This post describes that dissimilarity.

I am not excited about using Gen AI for software development. Not against it per se, just not terribly interested in it.

But work has been pushing us to use GenAI lately, so I've been (somewhat reluctantly) trying to incorporate it into my workflow.

A few months ago, I signed up for a ChatGPT account, used it for a few research questions, and then mostly ignored it.

This week, we all got Copilot licenses. This post is about my initial impressions of Copilot, and a couple of small wins using it in VSCode, while working on react-i18n translation files.

• Link dump
  • CI/CD YAML syntax reference | GitLab Docs
  • Predefined CI/CD variables reference | GitLab Docs
  • Terraform Registry
  • OpenTofu

• Terraform is an Infrastructure-as-Code (IaC) tool to manage your infrastructure resources using a declarative language called Hashicorp Configuration Language (HCL).
• Helm is a package manager for Kubernetes workloads, similar to something like apt-get or Homebrew.
• Terraform concepts
  • Declarative systems
    • In contrast with Procedural Systems, where you must tell the system the exact steps to take, in a Declarative System you describe your end goal and the system takes care of making reality (i.e. the live system) match your description.
      • This process is called “Convergence”
    • In Kube, the description is your manifest .yaml file and convergence is handled by the [[control loop]] and operators that understand certain Kinds of resources.
    • ArgoCD you can think of as a sort of Meta-declarative system on top of Kube. The description is the AppSets, and the Argo CD Controller handles convergence by polling your source code repos and running kubectl apply (well, via Helm). After that, the kube [[control loop]] takes over.
    • Crossplane is also a meta-declarative system, where the description is a kube manifest and the convergence is handled by terraform.
  • terraform plan command reference
    • This command will compare your statefile to your source code and emit a .tfplan file containing all the commands to bring the live state in line with the source.
  • terraform apply command reference
    • This command will execute the commands in the .tfplan file and write the updated state to the statefile
    • If your source code has changed since the plan file was created, it will be marked dirty and terraform apply will not run.
  • State file
    • https://developer.hashicorp.com/terraform/language/state
    • Purpose of Terraform State
    • Store the statefile in a bucket
      • You can keep it in your repo, and track in git, but don’t. It’s a binary file with a lot of churn.
    • Terraform only knows about the resources in your source code and your statefile.
      • If you have live infrastructure that is not represented in Terraform, you will have to define the terraform code, and then import the live state into your statefile
  • Input and output
    • Each module (see next item) can define input and output values.
      • Inputs take the form of variables
      • Outputs are stored in the statefile (IIRC)
      • The outputs of a module can be hooked up as the input to another module
  • A “Module” is the base unit or terraform configuration and is a collection of resources. It’s also a bit of an overloaded term, unfortunately. I will try to clarify
    • https://developer.hashicorp.com/terraform/language/modules
    • A “root module” is the root of your configuration. It must define providers (plugins for AWS, GCP, Azure, Digital Ocean, etc) to use, the backend (i.e. where to store the statefile), and might have some define some variables
    • A “child module” defined a re-usable configuration, with variables for input, but does not define a backend.
      • The root module can import these child modules.
      • For example, you could define a tagging convention for your resources in a child module and import into all or root modules to keep that resource tags consistent.
    • A “Stack” is basically a special type of child module, which defines a bunch of related infra intended to be imported into an environment
      • E.g. you might have a standard kube cluster stand which you use to create kube clusters in all environments
      • That stack might define not just the kube cluster itself, but also autoscaling node pools, and take the name of a VPC (created by another stack) and the name of the bucket to use for volume mounts
• Comparing Kapp, Kube, Crossplane and Terraform
  • We use Carvel - kapp for deploying kubernetes resources
    • Kapp assumes that the kube cluster exists
  • Terraform is for defining the kube cluster and related resources (e.g. the VPC its in or the bucket to use for volume mounts).
  • We also use Crossplane on our clusters to deploy cloud functions. Crossplane runs Terraform under the hood.

• These are my reading notes for Google SRE - What is Toil in SRE: Understanding Its Impact
• Goal of SRE is to spend most of your time on engineering project work, rather than operations
  • at google, the goal is < 50% toil, averaged over a few quarters to a year
• Note: Admin work is overhead, not toil
• "So what is toil? Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows. Not every task deemed toil has all these attributes, but the more closely work matches one or more of the following descriptions, the more likely it is to be toil: ..."
  • manual,
    • A script is automation, but if you have to run it manually, that part is toil
  • repetitive,
  • automatable,
    • if it requires "human judgement" each time, it doesn't qualify as automatable
  • tactical,
  • "devoid of enduring value",
    • "If your service remains in the same state after you have finished a task, the task was probably toil. If the task produced a permanent improvement in your service, it probably wasn’t toil, even if some amount of grunt work—such as digging into legacy code and configurations and straightening them out—was involved."
    • not clear what "in the same state" means. Perhaps maintenance tasks? Migrations?
  • scales linearly as a service grows
    • more scale => more work => more toil
• top source of toil: interrupts
• Not always bad, often necessary, but you don't want too much of it

For the longest time, the wallpapers on my external monitors just didn't show. Where there should have been a wallpaper, there was solid black.

Nothing else was wrong with the laptop, so when a few restarts didn't fix it, I didn't bother looking into it further. (It's an aesthetics issue and I usually have windows over it anyway, so who cares.)

I finally looked into it this morning, and you just have to restart the dock:

killall Dock

Some supervisor process somewhere restarts the dock and boom, my wallpapers are back. I'm not sure why a restart didn't do the same thing. Weird.