Alex Luong's Website

Netlify Drop - Easiest Way to Deploy HTML

2026-02-21T16:13:27Z

https://app.netlify.com/drop

Just want to shout out Netlify Drop as the easiest way I know to get an HTML file online. Drag and drop a folder or just index.html and the site is online. This has been the case since day one and I came back to this every once in a while whenever I need.

It's been a long long time since I used Netlify in production but they'll always have a place in my heart because of this. Kudos!

DeepakNess

2026-01-21T12:56:40Z

I came across Deepak website today online. Not 100% sure how, but that's unimportant. I really appreciate his general, casual vibe, the #noagendacalls which was something I used to do, as well as the his About page.

This is just a random note-to-self, more of a braindump and reminder to reach out to Deepak and grab a virtual coffee at some point.

host.docker.internal in Colima

2026-01-08T19:15:49Z

Hello world, it's been a minute!

Anyway, just want to leave a quick note. I've been playing around with Colima instead of Docker Desktop and ran into issues with host.docker.internal. Not 100% sure what the issue is yet but it seems 192.168.5.2 works. Seems it's a Colima thing.

This is just a note-to-self, TIL type thing.

Run golangci-lint locally with Docker

2025-02-06T14:10:12Z

I recently ran into some issues running golangci-lint locally. I suspected it's because I use asdf to manage my different Go versions. I was able to get around that by running the linter with Docker instead. It's unfortunately not very snappy, but it works for my current workflow for now, so I'm chalking that up as a win.

Here's the Docker command I use:

$ docker run --rm -v $(pwd):/app -w /app golangci/golangci-lint:latest golangci-lint run

Here comes Claude for the explanation. Hope this helps!

1: --rm: Automatically removes the container when it exits
2: -v $(pwd):/app:
- $(pwd) gets your current directory path
- Maps your local directory to /app in container
- Allows container to see your code
3: -w /app:
- Sets the working directory inside container
- Makes container run commands from /app directory
4: golangci-lint run -v:
- run: Starts the linting process
- -v: Verbose mode, shows more detailed output
- Checks code against rules defined in your .golangci.yml

[CollieLab] Initial Observability Stack

2024-11-05T16:39:04Z

This is the first entry of my "CollieLab" series where I documented my home lab journey.

The current state of the lab hardware is pretty straightforward: a single Vultr $6/m VPS with 1 CPU core & 1GB of RAM.

I've been rocking with this machine for the past month or two, hosting my personal site and a few toy projects without a hitch. Of course, there's not much traffic in any of these services, so not much going on there.

Anyway, I wanted to start monitoring the server as well as how my Docker containers are running. I spent some time the past few days setting up Grafana, Prometheus, Loki, and cAdvisor. Everything is super straightforward, so nothing crazy yet, but it feels good to have a sense of how my little machine is doing. Here's how the cAdvisor dashboard looks on Grafana, in all its glory.

My next plan: Analytics & Uptime Monitoring. Stay tuned.

Open Telemetry Remote Tracing in Go

2024-09-27T11:59:32Z

Earlier today, I tried to use OpenTelemetry for a custom instrumentation. Specifically, I want to track the lifecycle of an event throughout my whole system.

Previously, I mainly relied on auto instrumentation to generate traces, so this was the first time I worked with Otel tracing SDK. Here are my notes after a few hours playing around with it.

The goal is that every time I receive an event, I want to start a root trace. This event will then be executed and sent through a few queues for handling in different workers (or services). During this flow, each of these workers should add spans to this trace so that I can have a holistic view of what happens to each event.

First, when receiving a new event, this is how to start a new root trace:

import (
	"go.opentelemetry.io/otel"
	"go.opentelemetry.io/otel/attribute"
	"go.opentelemetry.io/otel/trace"
)

// ...

traceProvider := otel.GetTracerProvider()
tracer := traceProvider.Tracer("project/internal/packagename")

parentCtx := context.Background()
traceCtx, span := tracer.Start(parentCtx, "event lifecycle")
span.SetAttributes(attribute.String("event.id", event.ID))
defer span.End()

To break things down a bit, TraceProvider is the entrypoint for us to start tracing. This snippet will use the global trace provider, or we can accept a custom trace provider for some specific use case. Using trace provider, we can create a new Tracer instance. It's recommended that we provide a unique name (say the package name) so for a unique tracer instance scoped to that package only.

From then, we can start a new span within the trace from the parentCtx. In this example, as the parentCtx is a brand new context, this trace will be the root trace.

Next, whenever we process the event, we want to add spans to this context. To do so is fairly straightforward if we have access to that traceCtx. However, because the event processing happens in different services, we have to construct the context ourselves using the context's trace ID and span ID.

event.Metadata["trace_id"] = span.SpanContext().TraceID().String()
event.Metadata["span_id"] = span.SpanContext().SpanID().String()

// ... in event processing flow

parentCtx := trace.ContextWithRemoteSpanContext(context.Background(), spanContextFromEvent(event))
_, span := h.tracer.Start(parentCtx, "event processing")
defer span.End()

// ...

func spanContextFromEvent(event Event) (trace.SpanContext, error) {
	traceID, err := trace.TraceIDFromHex(event.Metadata["trace_id"])
	if err != nil {
		return trace.SpanContext{}, err
	}
	spanID, err := trace.SpanIDFromHex(event.Metadata["span_id"])
	if err != nil {
		return trace.SpanContext{}, err
	}
	return trace.NewSpanContext(trace.SpanContextConfig{
		TraceID:    traceID,
		SpanID:     spanID,
		TraceFlags: 01,
		Remote:     true,
	}), nil
}

For example, let's say we can pass trace ID and span ID along with the event via its metadata. When processing the event, we can reconstruct the parent context using these IDs like so. The idea is that we can construct a "remote" span context, with remote meaning the span takes place in a different process than the current running process.

With this snippet, we can observe that the "event processing" is a child span of the root "event lifecycle" span.

I think this is a fairly straightforward flow, but since I'm quite new to OpenTelemetry, it still took me a bit of time to figure out. I hope this has been helpful to you, if you've made it this far. Please feel free to contact me if you have any questions or if you'd like a small demo.

Read: How to set up and tear down unit tests in Go

2024-09-05T22:44:22Z

Article: How to set up and tear down unit tests in Go

I've been writing quite a bit of Go and getting comfortable with Go's testing. Everything feels really good and the test suite has made me so comfortable doing major refactors.

Anyway, I wanted to set up some `beforeEach` action and noticed Go doesn't have it built-in. As any self-respecting developer would do, I requested ChatGPT to cook up something. Instead, what I got was just a bunch of baloney. Thankfully, chef Google swept in and served up this very nice article. It's short and sweet and has a really nice setup. Check this out if you're in the mood for a treat such as this one.

Docker and Firewall

2024-09-02T12:34:27Z

I was today years old when I learned that running a Docker container may bypass the firewall rules you have set.

Granted, I'm a complete noob when it comes to self-hosting or Linux, so it does make sense. But still.

Usually, whenever I set up a new VPS, I always follow some sort of guide to set up a non-root account and some basic firewall rules. You know, for security reasons and whatnot. I've never run and managed a Docker container myself. Always some sort of cloud services like GCP Cloud Run or my favorite fly.io.

In an attempt to "go back to the basics", I've gone and rented a new VPS and hosted this site on it. The goal is to learn things I would never run into had I gone with a cloud provider. I didn't know I would run into them so soon.

So, here's the setup. I have a fresh Debian machine that I closed every port but 22 for SSH, 80 for HTTP, and 443 for HTTPS. Requests to port 80 and 443 are routed to Caddy, a reverse proxy, before getting routed to some port running locally. This website is powered by Pocketbase, so I used its default 8090 port. Pretty standard, I'd think.

This is the simplified Docker Compose file for the site:

services:
  app:
    image: alexluong/alexluong.com
    restart: unless-stopped
    ports:
      - "8090:8090"

In my server, I'd run docker-compose up to start the container, and off we go.

Earlier today, as I was hanging out on the internet, as one does, I came across someone sharing that their VPS was "hacked" through a Docker container running in a port that's supposedly blocked by Firewall. Apparently, it's a whole thing. I'm not going to (and not able to) dive much deeper into it. You can learn more about it here.

In my Docker Compose above, the line "ports: - 8090:8090" is to map the host 8090 port to the container's 8090 port. For the host, I've always thought it's localhost, because when I visit localhost:8090, it works. I was mistaken. Without specifying the hostname or IP address, it defaults to 0.0.0.0. And apparently, there's a difference between localhost (or 127.0.0.1) and 0.0.0.0.

127.0.0.1 is the local network. "localhost" is the usual hostname for it. So when you visit localhost, you're going to 127.0.0.1, which is the local network of your computer.

0.0.0.0 seems to be more. If something is listening on 0.0.0.0:8090, you can visit it via localhost:8090 or 127.0.0.1:8090. But anyone having access to your IP can also visit it via YOUR_IP:8090. Usually, you have firewall rules to prevent this, but in this case, Docker has bypassed it and unwantedly exposes your computer to the public.

Here's my updated configuration:

services:
  app:
    image: alexluong/alexluong.com
    restart: unless-stopped
    ports:
      - "127.0.0.1:8090:8090"

and this seems to have fixed the issue. We're now safe and secure, as far as I can tell.

This has been a fascinating experience, and I trust this is only the first of many mistakes I'll make as I continue my self-hosting journey. Here's to many more mistakes to come.

Website Redesign

2024-09-01T13:36:26Z

I've done it. After 4-5 years of inactivity, I've finally refreshed my personal website; this site you're on right here. I plan to write a more comprehensive article to elaborate on this decision as well as the process. For now, I'll leave this note here as a small declaration as the site has just gone live 5min ago.

The main goal of this redesign is to encourage myself to write more and share more about what's going on with me, both professionally and personally. We'll see if it's a success or if it's just the result of procrastination and/or shiny object syndrome. Only time will tell. Until next time.

Hello World

2024-08-30T21:56:48Z

Welcome to my new website. This is the first post, powered by PocketBase. Hope it's a good start for something much more consistent to come. Cheers!

React Battle: CRA vs Gatsby vs Next

2024-09-01T10:40:42Z

Comprehensive Guide to Twitter Webhook

2024-09-01T10:41:54Z

Tweet Scheduler - A Technical Retro

2024-09-01T10:42:52Z

A Journey Through Gatsby Build Process via Building a Plugin

2024-09-01T10:43:42Z

Creating Your First Gatsby Theme

2024-09-01T10:44:21Z

Gatsby ImageSharp from a URL

2024-09-01T10:48:49Z

First Non-MLH Hackathon

2024-09-01T10:48:36Z

First Open-Source Contribution

2024-09-01T10:48:17Z