Andri Óskarsson | andri.dk

Announcing EventPuffin

Fri, 11 Sep 2026 00:00:00 GMT

EventPuffin is an event-planning platform that makes it easy to coordinate with multiple people and invite guests.

Problem domain

Occasionally, I have to plan birthdays, trips or other social events with friends, family and sometimes work. The current landscape of planning events involves horrible platforms that lock you in, spam you and/or fill your screen with ads.

Sometimes it's simple and you can decide yourself, but sometimes you have to find a date that fits most people, or settle on a film most people want to see, etc. That's where people used to reach for Doodle - except you'd have to create multiple Doodles for multiple polls.

Then you need to know who's coming. Most people might have Facebook, so you have to create the event there. But, then there are people who are not on Facebook and don't want an account. Then you'd have to text or email them individually.

Vision

I want everyone to be able to participate in my events, regardless of what platforms they live on. It should be easy and self-explanatory to help decide, or RSVP. Grandma should be able to do it!

It's built for planning birthdays, trips to the cinema, a D&D campaign at a sommerhouse or your next meetup.

Walkthrough

Create an event

With EventPuffin everyone can create an event. You don't need an account - although if you'd like to log in on other devices, it's recommended.

Make a decision, or loop in others

The most common details like where and when are already suggested. But you can ask whatever you want, like which pizza toppings people would like or what board games to play in the summer house.

You decide who gets a vote. One link for deciders (votes, rsvp) and another link for guests (only rsvp).

Settle the poll, or roll the dice

After a while, it's time to make a decision. Then you can look at the answers, pick the obvious winner, decide yourself or roll the dice. You can also set a deadline for voting so that the poll closes itself automatically.

Invite guests

You can invite guests at any time. Sometimes it's good to send invites early, to reserve date and figure out the details later. You can control which details the guests can see - but you can always start with the RSVP.

Stay up to date, without spam

You and your people can follow along with live calendar links, RSS feeds or web notifications.

Questions

Why is it not a native app?

It's about barrier of entry. Both for us, but also for planners, deciders and guests. The app is made responsive, so it should work on any device.

Why log in with atproto?

Where other platforms are hungry for your private data, we'd like to avoid storing it. Even an email address is personally identifiable and subject to privacy laws. We'd like to help you do what you want, and move on with your life.

There's also another reason for using atproto. If you have an account and publish your event. We'll create a special calendar record on your atproto account which makes it visible on all supported platforms like atmo.rsvp. If you choose to unpublish your event, we'll delete the record for you again.

Special thanks

To my wife talented wife Louise for designing the logo, lending me her good taste and for putting up with me for so long. Mads, Jens, Ryan, Stefan and Ulrik who kept asking about the project until one of the prototypes made it into production.

Over-engineering our vacation in 2026

Sat, 27 Jun 2026 00:00:00 GMT

I am of two brains. I need structure, but I hate planning. We had decided to stay in Iceland for a few weeks while visiting family and attending family gatherings. But, that left a lot of empty columns in the calendar, and people asking me if we have any plans. I shrugged and asked if they had any ideas.

As time kept creeping in on me, I eventually decided that I should try to put some plan together. But, that sounded very boring - so I decided to create software to help me (reads yak-shaving).

The itch worth scratching

Every time we go on vacation there are a few dominating things that shape the rest of the trip. Our method of transportation and where we are sleeping. Then there are things we'd like to do, and the rest must be flexible for any chance of relaxation.

Itinerary

The pillars of our plan; accomidation and sleeping. Easily set from the first page. Both can span one or more days.

Places and Activities

It was important that this was structured, but not so structured that we'd hate using it. An activity can be anything (eating, partying, driving, flying) and each activity needs a location. Locations can be added via address, or pinning it on a map.

Here is where I should've stopped

For all intents and purposes, the tool was now complete. We could look at the itinerary and plan our vacation accordingly.

But, I kept going....

Syncing with our calendar

The tool generates a webcal subscription that can be copied into Google/Apple/etc calendars and it automatically updates as you iterate on your plan.

Read-only share link

I wanted to be able to show my family the plan without teaching them about my over-engineered tool, so it's possible to copy/paste a secret link and send it to them so they can see what the plan is.

Day-view (Today)

I wanted an overview that could tell we what we're doing today, tomorrow and not stress me out on any future details.

Map for all days, each day

Sometimes it's fun to visualize where you're going and see it on a map.

You can also zoom in on each day.

We're flying. Why not track flights?

I'd share a screenshot here, but I've already stretched the limits of my free AviationStack account. Their free tier has 100 lookups per month. Plenty for a single-user trip-platform, right?

In a "flying" activity, you can supply an optional IATA flight number and it will pull flight data 30m before departure and arrival. Then it will update the page with flight information (gate, delays, etc) and your calendar too!

Below is a screenshot of a test-flight from yesterday

Single-user? Why not multiple users

Today, I decided to add users to the platform. If you'd like to play with my little tool you can find it at trip.andri.dk. You'll need a passkey to create an account. Passwords are so 2025!

That's all

This was a surprisingly fun project. But, I still haven't planned our summer vacation yet. So, I should probably go do that now. Bye!

Still here?

I might was well put a few words on how this was made. With a scope like this, it should be pretty obvious that this was either done over multiple weeks/months, or assisted by AI.

What separates the vibe-coders from the agentic engineers?

Planning! Not the boring kind, like vacations. Code planning. I spent over half a day iterating on requirements, user-stories and implementation details before allowing allowing the AI to write any code.

Tech Stack

I went with a server-rendered Go application using Gastro. If you don't use your own framework, then who will? It also has Datastar, web-components and some minor JavaScript.

All behaviours have test-cases, and are usually implemented as http tests. I had the AI use a headless browser while implementing to test interactivity.

Database is SQLite and I'm using sqlc to generate type-safe ORM-like functions from the schema. Migrations are managed by Goose.

Conclusion

I'm pretty happy with how this turned out, and the code is surprisingly readable. Most importantly, there is absolutely no browser state/side-effects to spoil my day. Yet the application feels quite dynamic.

I would like to lean more into Datastar SSE patching and signals at some point. But, for now it's mostly just templates and form submittions.

Could I have written this by hand? Sure! But, it would've taken much longer and had less coverage. Besides, this is a low-stakes personal project that scratches an itch. I also used the frictions from this project, to improve Gastro.

Old dog, new tricks

Mon, 25 May 2026 00:00:00 GMT

As an old school programmer, I thought I'd write down my journey into agentic AI and reflect on it.

Why I love programming

I've been programming for as long as I remember. My parents bought an Amstrad CPC 128k (yes, that's the RAM size) and I was immediatly hooked, at the age of 8. After getting bored of the computer games it came with I turned my attention to the manual. It, being in a foreign language didn't stop me either.

Solving non-trivial problems is my passion and I've been using the computer to do that for a long time. I'd spend my entire workday programming, and then go home and work on side-projects.

Books as a reference material

Back when I was learning programming we had to rely on programming books to learn the syntax. There was no Stack Overflow, ChatGPT or even Google.

As the web matured, I hardly ever look at programming books. The Internet has a more up-to-date reference than paper could ever keep up with.

Era of AI auto-complete

When these large-language-models (LLM) started drawing attention I thought I'd try them out. My first impression was that they were a good way to look up documentation, code references and large amounts of text, as long as you were critical of the output.

Copilot, Cursor and code-completion were all the rage; but I found them more distracting than helpful. At this point I'm was using ChatGPT daily to look things up, but I didn't want these things touching my code or break my rhythm.

Coding Agents. Are they good now?

I was late to the party, but in 2026 I decided to give coding-agents a shot. I didn't really know what to expect, since the quality of what AI delivered was so bad. I had a tedious task of updating popular library that was interconnected all over the place. I could've done it by hand; but it probably would've taken a week.

Then the agent and I started planning. This was fundamentally different from telling it to do stuff and be disappointed. I was using the AI to explore and brainstorm a potential solution and the output wasn't code. The output was a markdown plan file. Only when I thought the plan was worth working on, would I let it start editing.

I was blown a way.

If the plan was good, it would produce mostly good code. Not hand-crafted, beautifully abstracted masterpiece of code. But, working code. I've worked for companies that used outsourcing, and I dare say that agentic-coding is far superior to handing over a project to an outsourcing company, only to throw it away 6 months later.

Not because the code is better, mind you. But, because of a much faster feedback loop.

Beyond tedious tasks

After offloading boring, time consuming tasks to AI, I was curious how it would fair at building stuff. But, I wasn't ready to let AI loose at the production codebase at work. Enter my graveyard of side-projects!

I get many ideas. And for years, I've been writing the idea, with a rough solution down in my notes and forget all about them. I've been doing that for years. Sometimes I'd do a prototype, buy a domain-name and then get bored of it.

First project was something I've wanted to do for a long time. Block ads via HTTP proxy instead of relying on browser extensions and after brainstorming on a plan for over an hour the agent asked me: "Ready to implement?". "Ehm, sure!". From my earlier experience I was skeptical of just letting it rip. So, I decided to force it to do Test Driven Development (TDD) in Go. After 2 evenings of hand-holding I had a working proxy server. This would've taken me months to do by myself.

Second project was a frustration with web templating in Go. I was surprised and annoyed by a lack of typings between Go code, and the standard templates. After a night of brainstorming with the agent it also ended with "Ready to implement?".

Both projects are working and relatively stable.

The mental trade-off

As many software developers are now learning, streaming text into your brain all day is exhausting. A normal day of a software development might consist of investigating an issue, talking to stake holders, talking with UX, drawing up a rough solution and iterate on the code.

All of these steps include a break, personal contact and often blockers. With agents, you are suddenly the bottleneck between the backlog and production. That's stressful.

Humans are also lazy by nature. What happens to a product when the feature is written by AI, the UX is done by AI, the programming and reviewing is done by AI? Who is steering the ship?!

Code Craftsmanship

As someone who likes to discuss design-patterns, security, testability, data modelling and other weird topics I'm concerned. Not because these things are less important now - but because it's too easy to offload these tasks to AI.

Writing code was never the hard problem. Production software isn't just some functional requirements in JIRA, mashed together with ones and zeroes. There's a business domain and a very long list of past decisions that might or might not be documented somewhere.

As Software Developers, we need to pick our battles. We probably won't be deciding where that curly-bracket is sitting or the name of each variable, and that's fine. But, we definitely should be thinking more about software architecture, design patterns and not delegate that to the AI.

Security. What security?

I remember someone giving me the sage advise of "Always validate your inputs". Yet, letting Claude access all your online services, your computer and run terminal commands on your computer is normal now. Where does Claude get its' input from? Well, everywhere. Everything it reads from your files, your skills and online resources can affect its' behavior.

What makes it worse is that we can't validate agent communication like we'd do with web-forms. Anthropic is famously using regex in their harness and hard-coding dangerous commands. The best solution I can think of is putting everything in a sandbox and regulate the sandbox according to the purpose of the specialised agent.

There are going to be some terrible casualties on the stock-market when prompt-injection really takes off.

Conclusion

As you may have guessed by reading this far, I'm conflicted!

What it eventually comes down to, is money. Is the potential reward worth the risk of burned out developers and lack of security? Maybe.

My personal take. If we can get the security part to a reasonable level, then I think that humans should focus on strategy and let the machines do tactics. I will keep using AI for investigating code-bases, summarising large amounts of information and code tasks. But, I will write my own emails, articles and abstractions and force myself to take breaks during the day.

Let's not outsource our thinking. We might forget how.

Gastro: Server side web framework for Go

Mon, 06 Apr 2026 00:00:00 GMT

Writing web applications in 2026

I've been creating web pages for a long time. I started with Microsoft Frontpage, graduated to plain HTML (think table layouts, font color, limited css) and then when PHP v3 dropped I started building web applications.

These applications were all server rendered, and when Google released Gmail/Calendar and everyone was like "The browser can do what?!". Then the user-experience we were offering with our template languages wasn't up to the task anymore. So, we adjusted and added jQuery to our applications with a splash of Bootstrap and it was OK for a while.

Then as the projects grew, these jQuery scripts grew from helpful to unmaintainable and we were starting to build business logic in two places. At the time, I championed for React (Grunt/Gulp, React Classes) to save our sanity and became a spokesperson for React for everyone who asked, and lots who didn't. The promise of composability was too strong to ignore!

Fast forward to 2026, and everything is React. We no longer use classes, but have sprinkled useEffects, dependency arrays and state all over the place. This has brought some serious complexity to web development to the point that people complain about JS fatigue (well before AI fatigue). Newly scaffolded projects have somewhere between 500 and 1000 dependencies and updating those isn't trivial either.

For client-heavy applications (that need to be), I still enjoy using React (Native); but for most of my work related tasks of CRUD pages, tables and forms I've been feeling regret for some time now. Did we pick the right tool for the job, or did we just pick what was closest?

Web development in Go

As I dealt with more client complexity at work, I found myself leaning more towards backend and specifically Go at home. Normal people have normal hobbies. I typically compensate for the lack of learning at work with a side-project or three.

But, writing web apps in Go isn't as nice as I thought. The built-in template engine is quite capable and widely used. But, even simple server rendered HTML pages require you to write markup in editors where you can either have partial template support, or partial HTML support. Then you have to write handlers, compile the templates, embed them and hope they run as you expected.

Existing solutions

The closest solution I could find at the time was Hugo; but I don't want to generate static HTML. I want to write web applications, like I did with PHP when I was young.

So, I started searching; but all of the frameworks were focused on routing and ORM-like libraries and very focused on being the fastest.

Templ was the first Go template language where my IDE was actually helpful. It's a custom DSL that with Go syntax, that generates a .go file for every .templ file you write. I really wanted to love Templ. But, the fact that I'm writing a Go project that populates my projects with generated Go files at every turn, was annoying me more than it should have.

Gomponents was also interesting to me. It's sort of like React, for Go. So every HTML-element has a generated function that you can use to write composable HTML with. It works, but I could never get used to writing HTML that way.

An inspiration from Astro

I was talking to my CTO the other day how I love Astro and how their server-side components are far superior to approaches by Next.js and others for a single reason. There is never any ambiguity about what runs on the server, and what runs on the client.

---
// Frontmatter always runs on the server.
interface Props {
    name string;
}

const { name } = Astro.props
---
<!-- body is HMTL sent to the client -->
<p>Hello {name}!</p>

So, Astro is great, and I almost left it at that. But, I want to write Go! I like that I can build applications with zero dependencies outside of the standard library and not be horrified when the next npm vulnerability pops up.

Gastro - as in gastronomy

I love food, and I wanted to recognize the influence Astro components had on the project. The goal of Gastro is:

Make web-development fun again
Learn from past mistakes.
- PHP was too unstructured and eventually ended up in tears
- React was an overcorrection to a painful SSR experience with modern UX
- Static types and full IDE support for a great developer experience
Use AI to do the heavy lifting
Server Side Rendering (SSR) only.
gastro dev will listen for changes and generate all the code in .gastro/.
gastro build should generated a binary, embedded with all assets and be ready to ship

Let me address the AI elephant in the room first. I enjoy writing code, and solving problems. But, as someone who has abandoned more pet-projects than most start in their lifetime; I like that I can outsource the tedious stuff, so I can focus on the actual problem solving.

A typical Gastro project

After installing Gastro on your machine, a typical workflow is like below. See Gastro's homepage for a better introduction.

gastro new awesomesauce # scaffolds a new project
cd aweseomesauce
code . # launch vscode (search for Gastro in the extension marketplace)

This will prompt you to install Go, gopls and Gastro (if you don't have it already). The project structure is opinionated, and simple.

/components: Put re-usable elements here and call them from pages. Components can call other components.
/pages: Any .gastro component will be treated as a page and added to the generated routes.
/static: Public assets are embedded and shipped. Accessible from /static on the server.
main.go: Your main project file. Here you can setup http multiplexing, move domain-logic into packages or whatever floats your gravy-boat.

Pages

Here we import a component using a special .gastro import statement. Title is exported (upper-case) to the template and validated in the template by our language server.

---
import (
	Hello "components/hello.gastro" // Imports Hello component
)

Title := "Welcome to Gastro" // Uppercase makes it visible to the template below
---
<!DOCTYPE html>
<html lang="en">
	<head>
		<meta charset="UTF-8">
		<meta name="viewport" content="width=device-width, initial-scale=1.0">
		<title>{{ .Title }}</title>
	</head>
	<body>
		<h1>{{.Title}}</h1>
		{{Hello (dict "Name" "sup")}}
		{{.Title}}
		<p>Edit <code>pages/index.gastro</code> to get started.</p>
	</body>
</html>

Components

The Props type defines what the props look like, and gastro.Props() makes them available in the frontmatter in a type-safe way. The ensures the language-server can verify and autocomplete the template variables in the body.

---
type Props struct {
	Name string
}

p := gastro.Props()
Name := p.Name
---

<div>
	<p>Hello {{.Name}}</p>
</div>

So, we're back to 2002?

Not exactly. In 2002 we didn't have web-components, JS modules in the browsers or hypermedia libraries like htmx and datastar. Modern CSS can also do many things that we previously needed JavaScript for.

I think we can have our server-rendered cake, and eat it too! I'm pretty happy with how the design turned out, and I think this is a sweet spot between composable HTML and the complexity that usually follows.

OK, you convinced me. What's next?

Check out Gastro's webpage, the GitHub repo and the examples. The Gastro page is written in Gastro, compiles in a few seconds and deploys as a single binary.

Gastro is still in early development, so there will be bugs and rough edges. I'd appreciate any feedback, so we can make it better.

Why your coding-agent should be writing Go

Wed, 01 Apr 2026 00:00:00 GMT

Go (or Golang for some) may not be the best-in-class language for everything, but I think it's ideally suited for LLM coding.

The community is special in a way that is a bit differrent than communities of other programming languages. There's a strong feeling of doing things "The right way", "The Go way", "Idiomatic" and "avoid external dependencies". For this reason, I find it much easier to browse open-source projects written in Go, than say TypeScript. Solutions are similar, even if the programmers are not.

Feedback is essential to any programmer and your performance is closely tied to how fast that feedback-loop is. Go has a number of features that help with returning feedback quickly to you, Claude, Codex or even Fred.

When Google started development of Go, they were struggling with long build-times, so one of the core features of Go is that it compiles very quickly. Think seconds, not minutes. Since Go is a statically typed language it also will refuse to compile on invalid syntax or unused import.

Testing is also built into the go command so running tests is as simple as go test. This makes it easy to write unit-tests and integration tests as you go. Race conditions can be surfaced by running go test -race.

Where you place curly-brackets, line-lines or spaces is also handled by go fmt so all code looks the same.

Go also has a rich standard-library so it reduces the need to install 3rd party libraries.

Why Go for LLMs?

When talking to programmers, their biggest complaints are things that Go is:

Overly verbose
Overly opinionated
Hostile to patterns from classic OOP languages
Lack of fancy language features

I sympathise, I do. But, all of these negative things are positive things when it comes to letting the AI write all your code. You want your AI written to code to be flat, easy to reason about. You want it to look like other code, so that it's easy to review it.

In a word. The code may be verbose, but it's more simple than what many other languages produce.

My experience, so far

I started using coding agents at work, as our CTO actively encourages us to try it out. Cursor and Copilot in the IDE never really clicked for me. These tools disrupted my train-of-thought in such a way that I rarely used them.

Then came Claude Code, OpenCode, Codex, etc. Changing the interface from micro-managing every line of code, to larger batches makes sense for me. I started with annoying, time-consuming tasks like cleaning up tech-debt and was pleasantly surprised. Then I connected the Sentry MCP and asked it to find root-causes of problems and that also worked brilliantly.

Then I decided to try "vibe coding" and quickly created an Expo app w. TypeScript and Jazz Tools. Next project was ublproxy in Go, where I was able to leverage red/green (test-first) to create an adblocking HTTP proxy in a few days.

While I'd call both projects a success, I notice that the agent struggles more with the TypeScript codebase. Each exploration run takes longer, it makes silly mistakes where it feels like for every 2 steps forward, we take 1 step back.

The Go project doesn't suffer from this, and I challenge you to try using Go for your project.

Reflections on the age of AI coding

I've been writing code since I discovered BASIC as an 8 year old playing with our first computer. I still enjoy writing it, but my true passion lies in problem solving. Leading an AI isn't that different from leading a junior developer, or a team in India - the feedback loop is just faster.

I was asked recently if I feel threatened by the AI gold-rush. I think we're going to see a big disruption in many jobs that have been considered AI-safe. However, I think that critical-thinking, domain-knowledge and the ability to understand problems has never been more important.

Learning new things is fun, and AI is just one more tool for the old toolbox. But, I imagine that there are specialists out there that haven't kept up with the times, or had any reason to. They might have a rude awakening at some point; but should remember that their real value is their domain knowledge and that's not going out of style!

I haven't quite made up my mind on coding-agents yet. But, for now I can see the value in getting a crazy side-project idea, and flesh it out in a couple of days instead of buying a domain and quietly punish myself every time I have to renew it.

Learning n8n and using it to promote my blog

Wed, 31 Dec 2025 00:00:00 GMT

I've been having a bunch of fun learning n8n during the holiday vacation. I've hooked it up so that when I write a blog post in my site, it's published to RSS and...

Checks if the URL is already processed, abort if it is
Content is summarized by an LLM (I'm lazy, sorry)
Stored in a data-table

Then occasionally, it checks if the post has been shared on social-media:

If it's shared already, abort
Create a post on Bluesky and store a reference to the at-protocol URL
Create a post on LinkedIn and store a reference to the post
Add Bluesky comments by fetching the atUri from an n8n web-hook

As a part of this process, I've also had to

Remove all of the social-media posting stuff from my blog. It has always felt like a scope-creep to have it here, so now it's a part of my n8n setup and if that dies, that's not the end of the world.
Redo how I'm generating open-graph images because my earlier way of doing it didn't feel quite right.
Setup hosting and automatic deployments on my own server via Dokploy
Create an alternative open-graph image for code-snippet like posts

Did you do anything interesting with your Holiday Vacation?

MySQL/MariaDB cheatsheet

Wed, 31 Dec 2025 00:00:00 GMT

A few useful snippets while using MariaDB/MySQL. Copied from my notes. Get ready for some YELLING.

-- show slave status without your eyes bleeding
SHOW SLAVE STATUS\G

-- show master status
SHOW MASTER STATUS\G

-- processes
SHOW PROCESSLIST;

-- show users
SELECT User, Host FROM mysql.user;

--- show permissions
SHOW GRANTS FOR 'username'@'host';

-- change password
ALTER USER 'repl'@'%' IDENTIFIED BY 'newpassword';
FLUSH PRIVILEGES;

--- setup replica
STOP SLAVE;
SET GLOBAL gtid_slave_pos='xxx';
CHANGE MASTER TO MASTER_HOST='xxx', MASTER_PORT=3306, MASTER_USER='replica', MASTER_PASSWORD='xxx', MASTER_USE_GTID=slave_pos, MASTER_CONNECT_RETRY=3, MASTER_SSL_VERIFY_SERVER_CERT=0;
START SLAVE;
SHOW SLAVE STATUS;

CHANGE MASTER TO MASTER_HOST='xxx', MASTER_PORT=3306, MASTER_USER='replica', MASTER_PASSWORD='xxx', MASTER_USE_GTID=slave_pos, MASTER_CONNECT_RETRY=3, MASTER_SSL_VERIFY_SERVER_CERT=0;

SET GLOBAL gtid_slave_pos='xxx'

--- show mysql version
SELECT @@version AS 'MySQL Version';

--- connection status
SHOW STATUS WHERE Variable_name IN ('Threads_connected','Max_used_connections');
SHOW VARIABLES LIKE 'max_connections';

Social-media images directly into PNG from JSX with Takumi

Mon, 29 Dec 2025 00:00:00 GMT

Improving engagement of your online content can come down to how it's previewed on social-media services. If you're like me, and not keen on creating these open-graph images by hand for every post then you can generate them programmatically.

Takumi

Takumi is a tool that receives JSX and outputs images. It has support for (some) CSS, Tailwind and HTML. We'll be using React's JSX in this example; but there's also a lower-level API you can use if you like. It can run on Node.js, or in the browser using WASM.

If your template looks like this

function Hello() {
  return (
    <div tw="bg-white w-full h-full flex items-center justify-center">
      <h1 tw="text-4xl font-bold">Hello</h1>
    </div>
  );
}

You'll receive something like this:

Astro SSR example

Most of the documentation is focused around Next.js. But, my framework of choice is Astro.

Create a handler in pages/blog/[...slug].og.ts. It will respond to anything at /blog/2025/whatever/you/want.og.

import { ImageResponse } from "@takumi-rs/image-response";

export async function GET({ params }: { params: Params }) {
  const { slug } = params;
  const post: CollectionEntry<"blog"> = await getPost(slug);
  // TODO: You should handle errors here

  return new ImageResponse(
    // Using createElement instead of JSX because file is TS, not TSX
    // - Replace OgImage with your component
    createElement(OgImage, { post: post }),
    {
      width: 1200,
      height: 630,
      format: "png", // webp, others supported
      headers: {
        "Cache-Control": "public, max-age=3600",
      },
    },
  );
}

// Simplified version of my getPost using a content-collection "blog"
async function getPost(slug: string): Promise<CollectionEntry<"blog">> {
  const post = await getEntry("blog", slug);
  if (!post) throw new Error("Post not found");
  return post;
}

My template

The template component looks like this:

With the following template

export function OgImage({ post }: { post: CollectionEntry<"blog"> }) {
  return (
    <div
      tw="bg-black w-full h-full flex flex-col justify-evenly text-white px-16 gap-6 py-8 "
      style={{
        backgroundImage: "linear-gradient(to bottom, #033359ff, black)",
      }}
    >
      <h1 id="title" tw="text-6xl font-bold">
        {post.data.title}
      </h1>

      <div tw="flex flex-col gap-8 text-3xl">
        <div id="post-meta" tw="flex flex-row gap-6">
          <img src="avatar" alt="avatar" tw="h-20 w-20 rounded-full" />
          <div tw="h-full flex flex-col justify-center">
            <span tw="font-bold">{site.author}</span>
            <span tw="text-gray-400">{dateToIsoDate(post.data.date)}</span>
          </div>
        </div>
        <div id="tags" tw="flex flex-row gap-4 font-semibold">
          {post.data.tags?.map((tag) => (
            <span tw="rounded-full bg-white text-black py-1.5 px-4">
              #{tag}
            </span>
          )) ?? null}
        </div>
      </div>
    </div>
  );
}

I'm using an image in my template. We need fetch it and pass it to Takomi in the persistedImages array of the response.

const persistentImages: Array<PersistentImage> = [
  {
    src: "avatar",
    data: readFileSync(path.join(process.cwd(), "public/img/coffee-art.jpg")),
  },
];

In the template above, we reference it with <img src="avatar">. Note that we're doing this in the module-scope to cache the image in memory. If you're tight on memory, you could do this as a part of the request handler. But, then it will be slower.

Conclusion

Takomi is an amazing tool to create images from markup. It supports Tailwind out of the box and it's not as heavy handed as running, say a full Google Chrome to generate a single image.

While I'm using this for server-side-rendering, it should work fine in static-site-generation (SSG) scenarios as well.

It's also not limited to Astro, Next.js or the framework of the week. It's written in Rust, and compiles to WASM.

If you're still reading this, please check out Takumi's documentation and make it your own.

Replacing Makefile, direnv, asdf and more with Mise

Sun, 31 Aug 2025 00:00:00 GMT

Have you ever joined a new project and then spend an entire day setting up your developer-environment? Worked on a large project where one of the many tech-debts are that nobody updated the runtime for 10 years, and now nobody dares touch it?

"What version of Java/Python/etc do I need to run the backend?"
"How do I start a dev server?"
"Can you send me that ENV file we use for DEV?"
"How do I run database migrations?"
"How do I update our SDK from the API spec?"

We'll be covering the following:

Tools: How you can make sure that you and your co-workers are running the correct runtime, build-tool or CLI.
ENV: Set project defaults for environment variables without forcing people to rename a .env.default file.
Tasks: Like "npm scripts", but for any language, sub-project or monorepo.
Docker: Leaner, cleaner Docker images
GitHub actions: Making sure our pipelines are running the same version as you.

Note: This guide may not work well on Windows and is aimed at Linux or Mac users.

Getting started

You'll need to install mise. There are multiple ways of doing that, but for simplicity's sake we'll do it with a curl-pipe.

curl https://mise.run | sh
mise --version
# mise 2025.x.x

Now, let's create a directory called "mise/" in the root of your repository.

Tools

Mise supports a varity of tools, and tool backends. For our purposes, we'll be asking it to install Node.js v20 and Go 1.24.

# mise.toml
[tools]
node = "v20"
go = "1.24"

Then we run mise install

# tells mise to trust the configuration in `mise/`
mise trust
mise install

Mise will now install your requested tool versions. You might notice that if you go into the parent directory (above your project) and try running go version or node --version it might show different versions. That is because these tool versions are scoped to your project.

You can also pop a configuration file into ~/.config/mise/config.toml and set defaults.

# ~/.config/mise/config.toml
[tools]
# Always have Node.js LTS installed
node = "lts"

Now, unless specified otherwise you'll have access to Node.js LTS in other projects. Running mise install will update it to the latest Long-Term-Support if that has changed since last time.

Another neat thing is that when working on larger projects, you can override sub-packages too

- ~/.config/mise/config.toml # defaults for your machine
- ~/pied-piper/mise.toml # project defaults
- ~/pied-piper/packages/algorithm/mise.toml # uses an older version of python

You're not limited to "dev tools" either. You can install pretty much anything that has a GitHub release, or a release page with binary files using tool backends.

For example, I use the GitHub CLI to create releases on another project like

gh release create "$VERSION" --target "$GITHUB_SHA" --title "md-social $VERSION" --generate-notes
gh release upload "$VERSION" dist/*.zip dist/*.gz

Normally, a script like that would have to check if "gh" is even installed. But, instead I define it as a tool and let Mise handle it.

# mise.toml
[tools]
# other tools
"ubi:cli/cli" = { version = "latest", exe = "gh" }

Environment Variables

You can also use these configuration files to control your environment.

# mise.toml
# *snip* tool stuff *snip*

[env]
_.file = '.env.defaults' # Loads default ENV file
_.path = './bin' # Adds your local bin/ directory to path
VERSION = "v0.0.1-dev" # custom variable

There is also support for templating, file loading, redactions, secrets and more.

Tasks

JavaScript developers might be familiar with npm scripts. This like that, only you can use it with any programming language.

Tasks can be defined decleratively in TOML, or as scripts in any language. Those are great for npm-like scripts that depend on each other.

Let's define our development environment in TOML below.

# mise.toml
[tools]
watchexec = latest # Listens for changes on the file-system

[tasks.dev]
description = "Development Environment"
run = "mise watch dev.*"

[tasks."dev:go"]
# restart if go files change
sources = ["go.mod", "**/*.go"]
description = "Go backend"
run = "go run ."

[tasks."dev:js"]
# vite is handling the file watching here
run = "npm run dev"
description = "TypeScript frontend"

Now, if you run mise run dev it will run both backend and frontend. Should any files change on the backend, it will automatically restart it for you.

For more complicated tasks (e.g. linting across packages, migrations, publishing, etc), I like to keep file-tasks in either scripts/ or tasks/ folders. You can also split your TOML tasks into files.

# mise.toml
# *snip* previous stuff *snip*
[task_config]
includes = [
    "tasks.toml",
    "scripts",
    "tasks",
]

Creating a file-based task is like creating a normal shell script.

#!/usr/bin/env bash
#MISE description="Deploy to Kubernetes"
echo kubectl stuff here

Place this in scripts/deploy and run chmod +x scripts/deploy.

mise tasks
# Name      Description
dev         your description here
dev:go
dev:js
deploy

In the "deploy" scenario, I might put a #MISE depends=["build"], to make it trigger a build before running the deployment script.

It's also worth mentioning, that you can have tasks for each of your repository projects. So if you only wanted to run the frontend, you could run mise run dev from "frontend/" and have its' mise.toml configure the "dev" task for something else.

Docker

If you've read this far, you might be thinking to yourself: "Why would I spend so much time doing this, when I need to do this again for our Dockerfile and our pipeline too?!"

You can also use Mise inside of Docker using their official image, or by running the curl command manually from a base-image of your choice.

FROM jdxcode/mise:latest AS tools
COPY mise.toml .
RUN mise trust
RUN mise install

# [DEPENDENCIES]
FROM tools AS dependencies

# Friends dont let friends run containers as root
RUN useradd -m -u 1000 app && mkdir -p /app && chown app:app /app
USER app
WORKDIR /app
COPY . .
RUN whatever you want

If you have nested configuration files, you'd have to adjust this to copy them as well in the first stage.

GitHub Actions

There's also an GitHub Action for Mise from its' creator.

Conclusion

Mise allows you to define how your development environment is set up, in one place and frees you up to focus on more important things. It can simplify containers and pipelines too.

The only thing that could make this setup more magical, would be if you could setup multi-language git-hooks for your monorepo too. Funny enough, JDX has you covered with a sibling project, hk.

If you find this project valuable, consider sponsoring him on GitHub.

Technical Scrolls for Bluesky

Tue, 31 Dec 2024 00:00:00 GMT

I've always been interested in technology, and not much else. When social networks emerged I was excited for all the technical content I'd have access to. Unfortunately big-tech has no interest in allowing us to control how we consume content. Facebook started out with allowing you to select all your interests so that they could better show you interesting things. Typing this out loud now, makes me think I was incredibly naive. Of course they did that so they could show me interesting ads. Twitter somehow was different, because I could selectively follow people who posted things that were interesting to me.

Try out Following Tech or Technical Scrolls and DM me on Bluesky if you have any feedback.

Selectively following

For a while, I got my fix of tech news from Twitter from a carefully selected group of people who mostly posted technical stuff. The "problem" with that approach, is that people are human and post things that they like. Google+ had an interesting concept of "circles" where you could post carefully curated content and people could only follow what they were interested in. Problem is, people don't like to do that and of all the people I had on G+, I was the only one using circles. People want to post whatever is on their mind, and that is perfectly understandable.

Now, you might be reading this and thinking that I must really hate people and their people posts. Not really. It's a matter of context. I may enjoy reading about what my friend had for lunch or see a drawing that their kid made for them. But, that does not mean I'm interested in kid-drawings or lunch photos for people I have no personal connection to.

So the closer you are to me, the more interested I am in reading whatever it is you're thinking. So, I have been pruning the list of people to follow for years, and sometimes that means missing out on some great, interesting content and engaging with interesting people who just wanted to share stuff they like.

Vision

I want a place on the Internet where I can read interesting technical posts. Experiences of problem solving, new libraries, JS framework of the week, crazy experiments or anything like that. Without the noise.

Enter Blue Sky

I was more invested in Mastodon/ActivityPub and even attempted to host my own personal instance for a while. It had it's upsides, but the protocol requires you to store a bunch of stuff that really has nothing to do with you or your users.

So when Bluesky started to get popular I had my doubts. Then Elon Musk and Donald Trump happened and Bluesky was flooded with millions of people and I saw a clear uptick in interesting technical content on the platform. But, that also came with what I would consider "noise". I get my fair share of "current events" from other sources, so I absolutely don't want to read about that here.

How hard can it be?

Every engineer probably has mumbled those words. I had read that Bluesky had this concept of "label services" and I immediately wanted to see if I could build a labeler for "technical" / "non-technical". But, after reading more about atProto I came to the conclusion that labeling everything that was not tech related would be an impossible task and add noise to an otherwise impressive protocol. Labels were meant as a form of moderation; to label what might be sensitive to others.

Feeds

If labels are an exclusion-list, then feeds are an inclusion-list. That sounded like the Internet I wanted, so during the Christmas holidays I started prototyping. I was put off by the amount of libraries and dependencies the examples were using; but eventually came across a few great examples of feed generators that were minimal in nature.

Then I created a feed that always showed a single post, using a HTTP endpoint. The only library used was the "@atproto/api" for registering the feed. Initial prototypes used Bun and almost no external dependencies.

OK, let's do this!

Tech Stack and challenges

I needed a web-server for /xrpc/app.bsky.feed.getFeedSkeleton and /.well-known/did.json. I needed somewhere to store the posts, their classification and I also wanted to build some moderation tools to make it easier for me to debug the classifiers.

TypeScript and Bun
Astro for the web-application in SSR mode
Postgres, Drizzle-ORM with postgres-js
React (as Astro interactive islands) for the moderation tools

Jetstream

The Bluesky firehose is massive and I'm not at all interested in burning a hole in my pocket while trying to process all of the 30 million users worth of posts. So, I opted in for using the Jetstream service and only subscribe to posts followed by my users.

I tried some libraries, but the most promising one had an issue with Bun and none of them supported compression. So like any overly optimistic programmer, I made my own. It's specifically designed to my use-case of requesting only the DID (user identities) I want from the service instead of "all posts". The Jetstream service supports up to 10000 accounts per socket and state that I can open as many sockets as I want. Challenge accepted!

My initial attempts went well, but as soon as I approached 200 accounts the socket refused to connect. I suspect that my query-string was too long, but I was a big issue, since even with one user (me) the service was opening 3 sockets.

Reading through some of the other libraries, I came across an option of Jetstream to update it's configuration through the socket instead of requesting it through the URL. That worked wonders, and I could easily fit all the requested accounts in one socket.

Looking at the posts quickly filling up my terminal's buffer I decided that I needed to get that stream compressed before I get a call from my ISP. Finding a zstd library was easy, but finding one that supported Bluesky's custom dictionary was harder. I finally found a great library called @bokuweb/zstd-wasm and quickly had the compressed stream working.

Classifier

You can't have a feed without knowing sort of what posts you want in your feed. I wanted something simple in the beginning so I'd have some content while trying to figure out the best way to classify posts as tech/non-tech. The first few classifiers use regular expressions to mute or tag posts according sentences that I've hard-coded. But, I designed the data-model so that any post can be tagged multiple times by different algorithms. That way, I could start simple and then bring GPT and friends if I came across a big pile of money.

Next attempt was creating my own naive bayes classifier; but I ended up spending more time than I had fine-tuning the tokenizer function and still wasn't seeing the results I wanted. But, at this time I knew I needed a way to manually classify posts to train the models.

I was desperate, so I reached out to ChatGPT. It was quite helpful, and suggested Tensorflow JS with a bit back and forth, ChatGPT and I were able to stitch together a promising tokenizer and bayes classifier. I then started to consider how I was going to store the model and it seemed that the Tensorflow either want you to use local-storage (browser) or raw files (node). But, I didn't want that... I wanted to store this in my trusty Postgres.

So, I wrote a custom IOHandler implementation, that was able to load and save models from the database with the dictionary.

Web application

What I want from the web application is to serve the feeds, be able to preview the feeds and most importantly, be able to classify manually. All of the API calls are implemented as Astro Actions (type-safe and zod validated).

I work with React in my day-job, so it felt natural to grab it for my moderation tools. Being naturally curious, I decided to go for React 19, fresh off the shelf and try their new use() function. Then my development environment started hammering the Bluesky API every few millisecond. Sorry Team Bluesky. After a few hours of scratching my head, I found out that the use() function is intended for content from react-server-components and any promises created on the client is re-created on every render. If you ask me, that's an accident waiting to happen. We (React users) have been hoping for a simpler way to consume API's on the frontend and I really thought that use() was it.

To preview the posts I started out with using react-embed-bluesky, which is excellent but intended for creating engagement on the platform. I wanted a simple preview, with moderator tools. But, it was a great inspiration - so thank you Hichem.

Database

I can't end this post without saying a few words about the heart of the solution. I've been programming professionally since the late 90's and was always a MySQL person. But, since I finally learned Postgres there really isn't any competition. Postgres is a work-horse and while it may not be best at everything; it's good enough at surprisingly everything.

I'm using Postgres to store posts, tags, classifier models and not to mention listen/notify that helps my processes communicate what posts need processing without me needing to invest in a full blown queue solution.

I've written harsh things about ORM (Object-Relational-Model) libraries, but Drizzle-ORM fits a sweet spot for me. It's strongly typed and it makes querying and storing stuff incredibly easy - just like every ORM. But, Drizzle has this wonderful "Magical sql operator" as they call it. As with any library, you will eventually find a use-case that it wasn't created for. But, with Drizzle you can use whatever SQL syntax your heart desires. So, I've come to like Drizzle very much.

The database is running on a small 512M node and it has performed admirably.

Conclusion

The service is running and mostly churning out technical content, but the holidays are soon over and I have other things to occupy my time.

What I'd really like to work on

In no special order

I'd love a "Programming memes" feed. It could be done by applying image classification models on. That would also mean more image content in the feed.
The services are leaking memory, and I can't tell if it's my crappy programming or some edge cases in Bun. I'd love to figure out why, and fix it.
So far the focus of my classifiers has been "relevancy" or figuring out if something is "tech" or "not". When the Technical Scrolls feed is so busy that it's unusable, I hope to spend some time on figuring out what's "trending" and "good" somehow.
If this gets popular I will need some help to train the models, and to do that I will have to do what I've been dreading. Implement oauth login and sessions.

This has been a really interesting project and I've learned a lot. Specifically about how Bluesky and atProto work, machine-learning and how (not) to write long-running JS services.

Still reading? Well, thank you so much. That means a lot!

Tech Podcasts for 2024

Wed, 14 Feb 2024 00:00:00 GMT

Some of the podcasts I enjoy during my bike-trip to work.

Soft Skills Engineering

Soft Skills are an underrated ability in engineers and Dave and Jamison deliver their advise in such a funny and helpful way that it's hard not to smile while listening to it.

Syntax.fm

Scott and Wes are really in touch with what's trending in the tech world and usually have both great guests and interesting takes on a various range of subjects.

Go time

A great Go(lang) specific show with deep technical topics and plenty of humor.

The Changelog

Good all-around tech podcast.

.NET Rocks

Even though I don't really program in .NET, I enjoy this show very much. Patterns and ways of working are universal and the hosts are very entertaining.

Darknet Diaries

Host interviews hackers and other cyber-criminals about their exploits and mistakes.

devtools.fm

Recently started listening, but so far very happy with their content which focuses on developer tooling (duh).

Home Assistant Podcast

As someone who likes tinkering with smart-home stuff, this show is very inspiring to what you can do with a few lines of Python or YAML.

JS Party

In depth show about all things JavaScript/TypeScript.

React Native Radio

A show from Infinite Red about React Native, Expo and the art of making cross platform apps.

Self Hosted

An inspiring show about software that you can host yourself without "the cloud". I may not do a lot of self hosting, but I enjoy listening to others talk about it in detail.

Shop Talk

Somewhat Ruby specific, but a great all-around tech pod cast.

Live reloading a Go web application

Tue, 19 Dec 2023 00:00:00 GMT

import video from "./live-reloading-golang.mp4";

I was playing around with server-rendering, and couldn't really find a good workflow for restarting the Go server, generate templates and generate CSS on changes without manually reloading it.

It's not quite as instant as hot-module-reloading in JS, but it's better than managing it yourself.

NPM dependencies

We're not really using NPM for anything except developer tooling, but you need it all the same.

npm init
npm install -D browser-sync concurrently nodemon tailwindcss

Go dependencies

If you're using Templ, then run...

go install github.com/a-h/templ/cmd/templ@latest

package.json

Then change the scripts portion of your package.json look like this.

{
  "name": "web",
  "version": "1.0.0",
  "description": "Note: Strictly used for dev tools. Not production",
  "main": "index.js",
  "private": true,
  "scripts": {
    "watch:go": "nodemon -e go,sql --exec 'go build . && ./app' --signal SIGTERM",
    "watch:css": "tailwindcss -i ./web/global.css -o ./web/public/generated.css --watch",
    "watch:templ": "templ generate --watch",
    "watch:browser": "browser-sync start --port 3001 --no-ui --proxy 'localhost:3000' --files ./app",
    "dev": "concurrently npm:watch:* --kill-others",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "browser-sync": "^2.29.3",
    "concurrently": "^8.2.2",
    "nodemon": "^3.0.2",
    "tailwindcss": "^3.3.6"
  }
}

Run it

npm run dev

Honorable mention

I tried using Air, but ended up dropping it for Nodemon. I already needed NPM for Tailwind (plugins), and it works great.

Declarative Software Environments

Thu, 14 Jul 2022 00:00:00 GMT

Someone smart, who works in infrastructure said to me recently (paraphrasing):

We can't have secure defaults on Kubernetes clusters, because the developers require full freedom to work on the cluster

I used to work as Linux System Administrator for 6 years before focusing on Software Development (10+ years). I honestly think developers want NOTHING to do with Kubernetes directly. That, however does not mean they don't want it running redundantly somewhere where it "just works (tm)" though.

What I want for my developers

I want the ability of continuous delivery. That the feedback loop for a single code change is as short as possible, with as little fallout as possible. Every single developer on my team, should be able to make a change and see it through to production.

Should we then teach every developer about DNS, clusters, schedulers, Kubernetes, Helm and the differences of each cloud provider? No! That is not the best use of their time and expertise.

Flow of a change

For a relatively standard stack, we have a database, some server code and some client code in a single repository.

Should any of these steps fail, abort.

Push to branch
- Create a new infrastructure-environment to stage the change
- New environment should have an exact copy of the database (partial copy if huge)
- Migrations are run on the database copy
- All services (and sites) are deployed (staged)
- End-to-End tests run
- Only for main/trunk branch
  - Migrations are run on the actual database
  - All services (and sites) are deployed
  - Production is ready
- Clean-up: Delete servers, databases and everything used in the transitional phase.

What is a declarative infrastructure

We define "what we want", but not the the "how we want it".

Git commit: This is how your world looks like at this very point in time
Infrastructure as Code (IaC): Describes what servers, services should look like
Database migrations: Describe how the database structure should like like
API schema: Describes the API (GraphQL, OpenAPI, gRPC, etc)

Reducing the barrier

I stated earlier, that I want every single developer to be able to follow through on a change to production. But, that doesn't mean that everyone needs to know about everything. They need to know just enough to being able to do their work in the best way possible.

"Jim, our frontend developer added a field to our API specification and made a change to our app"
"Tim, our backend developer saw a broken test due to an API change and fixed it on the backend"
"Kim, our ops consultant changed the number of instances for our API server to 3"
"Sim, our database admin increased the ram of our database and changed one of our INT fields to BIGINT"

In an infrastructure where this stuff is automated, they can comfortably change what they need without fearing that they have accidentally broken production.

Conclusion

The scenario I'm describing is absolutely doable, as long as we have test-coverage (I'm not talking percent's) of the stack as a whole so that anyone on the team can act in confidence. The only thing that I'm uncertain about, is how a large production database can be cloned easily enough for this to be quick. I've seen migrations pass in flying colours on test environments, only to fail in production. The data matters, but having pipelines finish quickly is important too.

As I write this, this is wishful thinking on my part. Our automations aren't quite there yet, but I think this little rant of mine illustrates what we want for our software teams and hopefully a little insight into how to get there.

Ideally, I'd like something like this for pull-requests:

const environment = makeEnvironment("feature/awesomesauce", "main");

Then it would look for the declaration files (from earlier), make the base from "main", then migrate it to "feature/awesomesauce" and deploy it, after all the tests pass.

Do you know of anything that might fit the bill? Please reach out.

Upgrading the home-network

Sun, 03 Jul 2022 00:00:00 GMT

Our home-network has been running on an Edgerouter Lite (now discontinued) for 8 years or so and it worked just fine. But, during the summer the heat in our garage has been exceeding 30C/86F degrees and it gave up on me. Now it peeps like a little bird when I turn it on.

Finding a replacement

So, I used to install Cisco equipment in another lifetime so I have a deep hatred for routers that attempt to do both WiFi and wired Internet. My router should route stuff, act as a firewall and maybe provide basic network services.

Requirements:

No WiFi
Have at least 3 gigabit ethernet ports
Run something that doesn't have a horrible security track record
Allow me to manually manage stuff like firewall rules/interface settings/routing

A friend from work recommended Mikrotik and while I wasn't terribly thrilled about the WiFi access-point I bought from them, I decided to give it a shot.

I settled on the Mikrotik. They publish throughput test results on their page and I really like that. Usually vendors try to hide stuff like that. But, given that I have a 1 gigabit connection to my house and it can throughput around 1.972 Mbps it sounded perfect.

The plan

Now that I had my router (props to Proshop for shipping it within 12 hours) I had an opportunity to plan the network a little better.

Conclusion

I'm very happy with the whole setup, except the cable-mess I spawned in our technical cabinet
Should the fiber fail, it will automatically route all the traffic through 4G (around 100mbit/s)
Automatically assigns a hostname to the external addres (regardless of fiber/4g)
VPN from my phone with Wireguard so I can access Home Assistant from wherever without exposing any services to the Internet

Tell me about your network setup?

Migrating to Astro

Sat, 02 Jul 2022 00:00:00 GMT

This site was originally built with Gatsby site in 2019 and I used it to teach myself Gatsby, React, GraphQL and Tailwind. Gatsby was a natural fit, because I was excited about both GraphQL and React at the time.

I've been considering migrating the site to either Next.js or Remix, but after playing around for a while I settled on Astro.

What the hell is Astro?

Astro is a static site generator (and SSR) that isn't stuck to a single framework. It supports most of them out of the box. The spoke to me, because I have a bunch of older React components that I wanted to reuse.

What's in the box?

TypeScript

Since I first created the site, I've learned TypeScript, so everything is now strictly typed.

Resumé

The page parses a JSON resume a creates the technology summary on the homepage, but also my cv. The enables the lazy dev that I am to update both my CV and homepage in one go.

The CV is rendered as an Astro page, as part of the build process, instead of as a post-build hook on the old site.

Social Cards

A site in 2022 isn't complete without being able to see a pretty preview when sharing on the larger networks.

When I created gatsby-plugin-social-cards, I used React to generate dynamic SVG files that sharp converted into png files. Sharp uses "fontconfig", so the fonts available when converting the SVG file are dependant on the machine. That made me lose interest in developing my social card plugin further.

Fast forward to 2022. I learned from a colleague that there is a Rust library called resvg that can convert to PNG and supports custom fonts! It even has a nice wrapper for JavaScript that I was able to use.

Astro already has a very nice social-card plugin called astro-social-images and much of the plumbing between my custom hack and Astro is based off of that. Right now, this works for my purposes, but I might open-source it later.

Storing the content

Here my story takes a sad turn. Clones of my site were popping up with the content in place, so I moved everything off Git and into Nextcloud. But dealing with images across different systems has become a real pain, so I've moved the content back into Git.

But until I come up with a better solution for keeping the content seperate from the source-code, my repository is now private. If you want to take a look, reach out and I will invite you until I find a better solution.

Other

React: Mostly for the resumé and a few minor components
Tailwind for styling

Final words

I already had a working Next.js branch, but a little Saturday project to see how troublesome it would be to move some of it to Astro turned into a full migration project.

My old React components worked out of the box, but most of the newer components are built as Astro components. The syntax is pretty clean and reminds me of Svelte. What finally sold me, was being able to render the resumé PDF directly from Astro.

My Gatsby site was always pretty fast, but I've never seen a Lighthouse score this nice before.

Was this overengineering? Absolutely! But it was very fun.

ENV files

Sat, 18 Dec 2021 00:00:00 GMT

An environmental-variable is a way for the environment (your operating-system, or shell) to share information with future processes. Some ENV vars are global (and set by the OS), others are only useful in a certain context.

You could be using a configuration file, but the world of hosting has very much adopted the 12 Factor App way of configuring applications. For environments like CI/CD, Heroku and Kubernetes, this makes a lot of sense.

In development though, this can be quite awkard to use.

Example: Backend API

You've written a beautiful monolith, but it needs a couple of things to run properly. It uses a private key to sign auth tokens, and it uses AWS credentials for uploads to S3.

You decide to use ENV variables and decide on AUTH_KEY and AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. Then you set up your hosting, and configure your app to abort if any of those are missing.

In development though, instead of running npm run dev, you now need to run AUTH_KEY=xxx AWS_ACCESS_KEY_ID=xxx AWS_SECRET_ACCESS_KEY=xxx npm run dev.

This is rather annoying, and might prompt you to write a blog post about ENV variables...

Creating the .env file

Instead of defining the ENV variables every time, we can create a .env file in our project workspace. It usually looks something like this.

# JWT encoding key
AUTH_KEY=youWillNeverGuessThisYouEvilHackers
# AWS Developer Access
AWS_ACCESS_KEY_ID=xxx
AWS_SECRET_ACCESS_KEY=xxx

You may be tempted to check this file into source control (e.g. Git) and store with your code. That would be a mistake. Especially if you decide at a later point to open-source your project. Then you'd also be giving everyone access to your AWS credentials. Even if you later delete the file from your repo.

Instead, add it to your .gitignore file to make sure that it will never get accidentally pushed with your code.

.env

It may not be 100% secure, to store stuff like this on your developer laptop, but it's still better than storing secrets in your repository.

Pro tip: New developers on your projects may not know anything about ENV variables or your local .env file. So make sure you update your documentation, and provide useful error messages if those ENV variables are missing.

Never create .env files for anything other than your development setup. It is very easy to accidentally expose secrets that way.

Reading the .env file

If we now run our backend, it will complain that our ENV variables are not set. We have to tell Node (or whatever) about those variables.

On Linux/Mac this is quite easy.

Pass the env-vars to MYCOMMAND

In this case npm run dev will have access to any ENV variables in the file.

eval $(egrep -v '^#' .env | xargs) npm run dev

Export the vars in .env into your shell

It's also possible to "export" the variables to your current session. That way, any command you run afterwards from the same shell will inherit it.

export $(egrep -v '^#' .env | xargs)
npm run build
npm run dev

Node.js

It is also possible to read ENV files without doing shell-script dark arts.

dotenv

You can inject the ENV variables into your Node.js process like this.

npm install --save-dev dotenv

In your app.js

require("dotenv").config();

In my experience, this is a horrible way of reading the ENV file. Remember, that this is a convenience for development. Why are we adding it to production code?

dotenv, without polluting your code

Add a file called local-dev.js to your project workspace.

const { execSync } = require("child_process");

// This reads the .env file into the environment
//  and shares it with any child process
require("dotenv").config();

const [argnode, argcmd, ...argrest] = process.argv;

// Run whatever follows `node env.js` as a child process and inherit stdin/stdout/etc
execSync(argrest.join(" "), {
  stdio: "inherit",
});

Then in your package.json. In my example, I'm loading .env and then running the Remix dev-server.

{
  "name": "your package"
  "scripts": {
    "dev": "node ./local-dev.js npm run dev:server",
	"dev:server": "remix dev"
  }
}

There are packages on NPM that do this for you, like dotenv-cli or dotenv-run-script. But why install a dependency for 4 lines of code?

Notable mentions

direnv can automatically load variables into (and out of) the environment as you enter directories with .envrc files.

Host Static Websites on a VPS with TLS

Sun, 02 May 2021 00:00:00 GMT

Hosting doesn't have to be complicated or expensive. I'll show you how to host a static site for $6/mo on DigitalOcean (ref link).

Be warned, this is a bit technical and you will need to type some things into a terminal. I will explain what each line does on the way.

Creating the server

Log on to the DigitalOcean cloud console and create a new Droplet.

Distribution: Ubuntu LTS or Debian is fine
Plan: Basic
Options: AMD, $6/mo (1G ram, 20G SSD, 1TB bandwidth)
Datacenter: Just pick the one closest to you.
Authentication: Pick a password or use a public SSH key (i use SSH keys).
Hostname: Something that helps you remember. Mine is called "hostingdemo"

DigitalOcean offers automatic backups for $9.60/mo and you can select that if you want, but in our case... we'll be building the site elsewhere and uploading it.

After a few seconds, you should see your server ready.

Logging on to the server

Note the IP address field. Click it to copy the address. You need SSH. It should already be installed on your Linux, Mac or Windows machine.

In your terminal shell (open terminal og cmd).

ssh root@your-droplet-ip-address

If you selected a password, you'll be prompted for that. If you selected an SSH key and that key is setup on your machine you're all logged in.

Installing what we need

We'll be using Caddy for our web-server to use its' automatic TLS feature. Other options could be nginx or apache.

# Install the web server
apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo apt-key add -
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee -a /etc/apt/sources.list.d/caddy-stable.list
apt update
apt install caddy
# Update your server, highly recommended
apt dist-upgrade -y

Now open a browser and access http://your-droplet-ip-address

That was easy, right?

Adding a web user to upload with

So far, we've been using "root", a system user that can do anything. We don't want to spread that around. Create a new user:

useradd webuser --password somethingstronger -s /sbin/nologin -m

This creates "webuser" with the password "somethingstronger" (and I do mean, it... use your own strong password), disables the SSH login and creates a home directory.

Enabling SFTP

To be able to upload files from a non-privleged user we need to change the SSH configuration a bit. Open the SSH daemon config in "/etc/ssh/sshd_config".

nano /etc/ssh/sshd_config

Make sure that the following lines look like this:

Subsystem       sftp    internal-sftp
PasswordAuthentication yes

The first one enables use of SFTP without having a login shell (like our limited webuser) and the second allows password logins for SSH.

Restart the SSH server

service ssh restart

Test the login from your machine (this works on Mac and Linux, unsure about Windows)

sftp webuser@your-droplet-ip

webuser@your-droplet-ip's password:
Connected to your-droplet-ip.
sftp>

Tell Caddy to serve files from our webuser directory

nano /etc/caddy/Caddyfile

:80

# Set this path to your site's directory.
root * /home/webuser

# Enable the static file server.
file_server

# Refer to the Caddy docs for more information:
# https://caddyserver.com/docs/caddyfile

This tells Caddy to serve from the webuser home directory instead. But, we need to give it access.

usermod -a -G webuser caddy
service caddy restart

Test the web-server

Upload an "index.html" to your server. Use whatever SFTP client you like (like FileZilla or winscp). From my local machine, I create a simple HTML file on my computer called "index.html" with "hello world" in it. Then I uploaded it to our server.

sftp sftp webuser@your-droplet-ip
put index.html

Adding a hostname or a domain

I added a DNS record to give my server a name. How exactly you add this depends on your DNS hosting provider. DigitalOcean has this under "Networking -> Domains".

Hostname: whateveryouwant (I used "hostingdemo")
Record Type: A
Target: your-droplet-ip-address

Now, if I point a browser to http://hostingdemo.andri.dk...

Adding Encryption (TLS/SSL)

To do this, we open our Caddyfile again in "/etc/caddy/Caddyfile" and change it to the following:

hostingdemo.andri.dk # replace this with your hostname

# Set this path to your site's directory.
root * /home/webuser

# Enable the static file server.
file_server

# Refer to the Caddy docs for more information:
# https://caddyserver.com/docs/caddyfile

Reload the configuration.

service caddy reload

Then in your browser change the URL from "http" to "https" and reload.

Wrapping up

We created a new server on DigitalOcean
We added a new non-privileged user "webuser" and configured it to upload the site
We setup a DNS name for our new site
We setup Caddy with automatic TLS using Lets Encrypt

Bonus

Automatically upload your Jamstack site with Github Actions

This is covered in more details in my Deploy your Static Site Anywhere post, but copy paste the following into a .github/workflows/deploy.yaml file in your repo on Github.

You need the following secrets set up on your repo:

SFTP_HOST: host or ip of droplet
SFTP_USER: webuser
SFTP_PASS: yourverysecretpassword

name: buildpack
on: [push, pull_request]
jobs:
  remote-build:
    runs-on: ubuntu-latest
    container:
      image: docker:stable
      volumes:
        - /home/runner:/workspace
    env:
      IMG_NAME: ${{ github.workflow }}
      NODE_ENV: production # Makes this a little more clean on the Node side
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Login to GitHub Container Registry
        uses: docker/login-action@v1
        with:
          registry: ghcr.io
          username: ${{ github.repository_owner }}
          password: ${{ secrets.GITHUB_TOKEN }}

      # Downloads and caches the pack command (the code is open)
      - uses: andrioid/setup-pack@main
      # Attempt to fetch any previous image so that we may use it for caching
      - run: docker pull ghcr.io/${GITHUB_REPOSITORY}/${IMG_NAME} || true
      # Builds your site with buildpacks (heroku builder)
      - run: pack build ghcr.io/${GITHUB_REPOSITORY}/${IMG_NAME} --builder=heroku/buildpacks:20
      # Pushes your new image to Github's Container Registry
      - run: docker push ghcr.io/${GITHUB_REPOSITORY}/${IMG_NAME}
      # Copy the build assets from the container and cleanup
      - run: CONTAINER_ID=$(docker create ghcr.io/${GITHUB_REPOSITORY}/${IMG_NAME}:latest /bin/sh) && docker cp ${CONTAINER_ID}:/workspace/public . && docker rm ${CONTAINER_ID}
      - run: ls -alh public
      - uses: actions/upload-artifact@v2
        with:
          name: public
          path: public/

  deploy-via-sftp:
    needs: remote-build
    runs-on: ubuntu-latest
    env:
      RCLONE_CONFIG_VPS_TYPE: sftp
      RCLONE_CONFIG_VPS_HOST: ${{ secrets.SFTP_HOST }}
      RCLONE_CONFIG_VPS_USER: ${{ secrets.SFTP_USER }}
      RCLONE_CONFIG_VPS_PASS_PLAIN: ${{ secrets.SFTP_PASS }}
    steps:
      - uses: andrioid/setup-rclone-action@main
      - uses: actions/download-artifact@v2
        with:
          name: public
          path: public
      - run: echo "RCLONE_CONFIG_VPS_PASS=$(rclone obscure ${RCLONE_CONFIG_VPS_PASS_PLAIN})" >> $GITHUB_ENV
      - run: rclone -v copy public vps:.

This requires you to have a repository on Github and that your site can be built with Buildpacks. I have this running with Gatsby, but it should work with almost anything that builds into public/.

Now my Jamstack Example site is deployed on our VPS!

Deploy Static Websites Anywhere

Sat, 01 May 2021 00:00:00 GMT

Before I started my carrier in Software Development, I was a System- and Network Administrator. I used to setup web servers and managed my own little server room. I truly, do not miss upgrading operating-systems on live services or dealing with hardware failure. However, hosting web-pages back then was much easier. You'd get an FTP/SFTP access and you'd upload your files. Then they got served statically...

Today, everything is about scale and maybe prematurely so. If you want to host a typical static site today, many hosting providers force you to add a Github (or similar) integration to your repository. To be fair; these providers offer automatic TLS, CDN, fail over and full scaling. But, what if I want to upload my own files? What if I already have a build-pipeline somewhere? Then this forced build-process is not convenient, but quite annoying.

I'm going to show you how to break free and deploy your static site wherever you want, using nothing but Github Actions.

Our toolbox for today

Github Actions: Github's build pipeline. This can be done on any CI platform. I simply chose Github actions because almost everyone uses Github and it's free for open source projects.
rclone: A wonderful file-syncing tool that supports a whole range of services.
Buildpacks: Build almost any project without writing a single Dockerfile. It detects your project, handles caching and has been used in production at Heroku for a very long time.

You also need node.js and git installed before we proceed. This guide expects that you know how to work with Git and Github.

TLDR;

If you're anything like me, you just want to skip the bullshit and dive straight into the code.

Setting up our sample Gatsby site

This could be any type of static site. I decided to go with Gatsby, because that's what I'm using. The only thing we assume here, is that npm run build works and builds to public/. Otherwise you have to adjust for it yourself.

Note: If you already have a site you want to deploy, you can skip this part.

npm init gatsby
# follow the prompts

Note: If you enabled the feed or sitemap plugins you need to add a metadata.siteUrl to your gatsby-config.js.

cd jamstack-example # or whatever you named yours
npm run develop # if you want to play with it
npm run build

Now you have a site in public/ that is ready to be deployed. Let's try it out real quick before going on to the Github part.

npm run serve

Then direct your browser to http://localhost:9000. If everything went well, you should see this.

Building it with Actions

Log on to Github and create a new repo. On that repo, find the repository URL and copy it where it says <repo>.

git remote add origin <repo>
git branch -M main
git push -u origin main

Now then. Let's add some actions! Create a file with this name and add it to your project.

.github/workflows/deploy-anywhere.yml

name: buildpack
on: [push, pull_request]
jobs:
  remote-build:
    runs-on: ubuntu-latest
    container:
      image: docker:stable
      volumes:
        - /home/runner:/workspace
    env:
      IMG_NAME: ${{ github.workflow }}
      NODE_ENV: production # Makes this a little more clean on the Node side
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Login to GitHub Container Registry
        uses: docker/login-action@v1
        with:
          registry: ghcr.io
          username: ${{ github.repository_owner }}
          password: ${{ secrets.GITHUB_TOKEN }}

      # Downloads and caches the pack command (the code is open)
      - uses: andrioid/setup-pack@main
      # Attempt to fetch any previous image so that we may use it for caching
      - run: docker pull ghcr.io/${GITHUB_REPOSITORY}/${IMG_NAME} || true
      # Builds your site with buildpacks (heroku builder)
      - run: pack build ghcr.io/${GITHUB_REPOSITORY}/${IMG_NAME} --builder=heroku/buildpacks:20
      # Pushes your new image to Github's Container Registry
      - run: docker push ghcr.io/${GITHUB_REPOSITORY}/${IMG_NAME}
      # Copy the build assets from the container and cleanup
      - run: CONTAINER_ID=$(docker create ghcr.io/${GITHUB_REPOSITORY}/${IMG_NAME}:latest /bin/sh) && docker cp ${CONTAINER_ID}:/workspace/public . && docker rm ${CONTAINER_ID}
      - run: ls -alh public
      - uses: actions/upload-artifact@v2
        with:
          name: public
          path: public/

It goes without saying that you need to add, commit and push this change afterwards.

Deploy to AWS S3

Amazon's S3 is one of the oldest managed cloud service and it shows why. It's capable to act as a bin for all your files, yet also supports things like static hosting and rewrites.

Create a bucket

Log on to AWS management console and find the S3 page. Create a bucket and note the ARN name.

IAM & access control

One of the most painful AWS experiences, is how we deal with permissions. I've done this many times, but I have to look it up every time.

Create a user with IAM and assign the following permissions with a new policy. Replace MYBUCKET with your ARN from earlier. Mine is "arn:aws:s3:::jamstack-example.andri.dk/".

jamstack-policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:PutObjectAcl"
            ],
            "Resource": [
                "MYBUCKET",
                "MYBUCKET/*"
            ]
        }
    ]
}

This policy allows your user to upload, download, list files, delete objects and upload with permissions (rclone uses this to apply your acl). The resources limit this permission to this single bucket (a good idea!).

TLS / SSL

Some services do this automatically, but AWS requires you to do this manually. I didn't add TLS to my example site, but you can take a look at this this blog post on how to add TLS to your S3 hosted site.

All done!

The site is now deployed on AWS S3.

Doing with any S3/SFTP any site isn't much different from the S3 example. In the appendix, I'll provide a few more examples.

deploy-aws-s3:
  needs: remote-build
  runs-on: ubuntu-latest
  env:
    RCLONE_CONFIG_AWSS3_TYPE: s3
    RCLONE_CONFIG_AWSS3_ACCESS_KEY_ID: ${{ secrets.S3_KEY_ID }}
    RCLONE_CONFIG_AWSS3_SECRET_ACCESS_KEY: ${{ secrets.S3_SECRET_ACCESS_KEY }}
    RCLONE_CONFIG_AWSS3_REGION: eu-central-1 # yours may differ
    RCLONE_CONFIG_AWSS3_ACL: "public-read"
    BUCKETNAME: jamstack-example.andri.dk
  steps:
    - uses: andrioid/setup-rclone-action@main
    - uses: actions/download-artifact@v2
      with:
        name: public
        path: public
    - run: ls -alh
    - run: rclone ls awss3:${BUCKETNAME}
    - run: rclone -v copy public awss3:${BUCKETNAME}

This is how my deploy-aws-s3 job looks in my workflow file.

You can see the site in action here.

Deploy to Netlify

To be able to upload files to Netlify, you have to create a new site. To create a site without adding a Git repo, you can go to the "Sites" page and in the bottom there is a drag-drop area where you can drop your "public" directory to create a new site.

When that is done, you can use the following job definition. Just grab the Site API ID from the site-settings page.

deploy-netlify:
  needs: remote-build
  runs-on: ubuntu-latest
  steps:
    - uses: actions/download-artifact@v2
      with:
        name: public
        path: public
    - uses: jsmrcaga/action-netlify-deploy@v1.1.0
      with:
        NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_TOKEN }}
        NETLIFY_DEPLOY_TO_PROD: true
        NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}
        BUILD_DIRECTORY: public

You can see the site in action here.

Deploy to Github Pages

Github Pages uses Git, and if you have a project that you want to use for Github Pages you can just create an empty "gh-pages" branch and use it to update your site.

For this blog-post, I created "andrioid/jamstack-example" and I'm using that for a demo deployment.

To setup our pages branch, do the following. Credit.

git checkout --orphan gh-pages
git rm -rf .
git commit --allow-empty -m "root commit"
git push -u origin gh-pages

This creates a branch named "gh-pages" without any commit history. Then deletes all of the tracked files. Then we add an empty commit and push it. Github will automatically set Pages up when the branch is named "gh-pages".

The only remaining thing is to use our build-step to upload the site to this branch. Fortunately there is an action that does just that.

deploy-ghpages:
  needs: remote-build
  runs-on: ubuntu-latest
  steps:
    - name: Checkout
      uses: actions/checkout@v2 # needed to setup git
    - uses: actions/download-artifact@v2
      with:
        name: public
        path: public
    - uses: JamesIves/github-pages-deploy-action@4.1.1
      with:
        branch: gh-pages
        folder: public

Add this job to your deploy-anywhere.yaml file.

You can see the site in action here.

Deploy to Neocities

Neocities offers free hosting and if you upgrade you can have TLS and a custom domain as well. They also support Webdav and that would allow us to upload with rclone (just like we did with S3), but I don't have a premium account.

So, to get this running we grab the Deploy to Neocities action. You can find your API key in the Neocities Site Settings. Add it to your repo secrets as "NEOCITIES_API_KEY".

deploy-neocities:
  needs: remote-build
  runs-on: ubuntu-latest
  steps:
    - uses: actions/download-artifact@v2
      with:
        name: public
        path: public
    - name: Deploy to neocities
      uses: bcomnes/deploy-to-neocities@v1
      with:
        api_token: ${{ secrets.NEOCITIES_API_KEY }}
        cleanup: false
        dist_dir: public

Add this job to your deploy-anywhere.yaml file.

You can see the site in action here.

Deploy to SFTP

I setup a small webserver with automatic TLS on DigitalOcean to demonstrate SFTP. You can read about it here.

You need the following secrets set up on your repo:

SFTP_HOST: host or ip of sftp server
SFTP_USER: webuser
SFTP_PASS: yourverysecretpassword

Add this job to your deploy-anywhere.yaml file.

deploy-via-sftp:
  needs: remote-build
  runs-on: ubuntu-latest
  env:
    RCLONE_CONFIG_VPS_TYPE: sftp
    RCLONE_CONFIG_VPS_HOST: ${{ secrets.SFTP_HOST }}
    RCLONE_CONFIG_VPS_USER: ${{ secrets.SFTP_USER }}
    RCLONE_CONFIG_VPS_PASS_PLAIN: ${{ secrets.SFTP_PASS }}
  steps:
    - uses: andrioid/setup-rclone-action@main
    - uses: actions/download-artifact@v2
      with:
        name: public
        path: public
    - run: echo "RCLONE_CONFIG_VPS_PASS=$(rclone obscure ${RCLONE_CONFIG_VPS_PASS_PLAIN})" >> $GITHUB_ENV
    - run: rclone -v copy public vps:.

You can see the site in action here. This link may stop working when I decide that I don't want to pay $5/mo for it.

Additional Hosting Providers?

Please drop me a line on Twitter if you want to add a hosting provider to this post. The only requirement is that it's possible to create the project without Git integration.

Deploy to Vercel 🚫️

Before Vercel was Zeit, their CLI now was able to take any folder and make it a website. But, it doesn't look like Vercel allows any of that anymore. I also can't find a way to create a project without integrating with a Git hosting provider.

Deploy to DigitalOcean 🚫️

DigitalOcean Spaces was actually my first attempt, but only after getting almost everything working, I realized that they don't support indexes. So, I had everything up and running with their CDN, but I had to manually link to "index.html".

As far as I know, there is no way of manually uploading files to their "Static Apps" offering.

Final words

When I started writing this post, I was sure that most of the hosting providers did in fact support open standards like SFTP, Webdav or even S3. But, that's not the case and that makes me sad.

Why those providers have the need to dominate our workflows is beyond my understanding. After all, what we're uploading here isn't any different than classic websites. All we need is a web-server. Everything else is just gravy.

Appendix

How to copy files from a Docker image

docker create $image  # returns container ID
docker cp $container_id:$source_path $destination_path
docker rm $container_id

Blogging with Obsidian, Gatsby and Nextcloud

Sat, 24 Apr 2021 00:00:00 GMT

Finding the motivation to blog has always been hard for me. Sometimes, because I have nothing to blog about, and that's fair. But sometimes it is because I'm not on a computer with my Gatsby site setup, or I just want to write something down quick.

Maybe unsurprising, I have the same problem with note-taking and I've attempted and abandoned countless platforms. Recently I bought Nextcloud hosting for my photos and I can happily report that my photos and files are synchronized nicely. Then I discovered Obsidian and found that using Nextcloud to sync my notes allowed my to have them everywhere.

Obsidian is a markdown editor, with a twist. It offers zeitgeist or outliner features that otherwise were limited to expensive tools or org-mode in Emacs.

I use it for work, for my daily notes, recipies and now recently, blogging. In case you're curious of the theme, it's California Coast and a few plugins. Send me a DM if you want the list.

What I wanted from the workflow

Write stuff in Obsidian on any of my computers.
Add frontmatter tags to my blog-post.
Go to bed and have my site automatically updated if there are any new posts.
Wake up the next morning and read comments about my blog post.

If you're thinking...

Then you're absolutely right. But if you can't overengineer your personal projects, then there is something wrong with the world. Image credit.

Before we get started

You can skip this if you don't plan on repeating my experiment.

I must add that this isn't exactly production ready, since I had to modify some plugins to make this work. Proceed at your own risk.

Install or sign up for Nextcloud
Install Nextcloud client
Install Obsidian
Setup a new Gatsby site or use an existing one.

Setting up your vault

I have a one big vault in Obsidian and source my blog posts from blog/. So anything in there will get picked up by Gatsby (more on that later). Nextcloud will sync your files across all of your computers.

Writing Markdown is easy, but if you want to know more, I recommend Github's Mastering Markdown.

Obsidian also supports drag-and-drop on images, so I just drop them into my editor and Obsidian copies the files.

Note: By default, Obsidian puts them in the root of your vault. I have "Files & Links > Default Location for New Attachments" set to "Same folder as current file". Also be sure to set "Use [[Wikilinks]]" to "false".

Writing blog posts

At this point you have Obsidian setup and Nextcloud syncing your files to a server. Create a new file in blog/2021/testing.md and add some frontmatter data to it.

```md
---
title: Overriding blog title
tags: ["gatsby", "nextcloud", "obsidian"]
---

## I am a test blog post

Fear my grammar skills!

```

Syncing to Nextcloud

After you've created your first blog-post, check your Nextcloud instance to verify the changes were synced.

I use a seperate user that only has read-access to my blog directory for security reasons, but to keep things simple; I'm going to skip that part.

Enter the Great Gatsby

Installing the plugins

You need to install the following plugins for this to work.

@andrioid/gatsby-source-webdav: Allows us to fetch Gatsby nodes from webdav. This is basically this with a newer version of webdav and support for remark nodes. I tried getting a PR merged, but received no response. I'd be happy to try again if the author wishes me to.
gatsby-remark-webdav: Something i hacked together. Not ready to release on NPM yet. Only use this if you need image assets from webdav. It parses your markdown posts from webdav and searches for images. If then copies the images and makes relative links work during the build process.

npm install --save @andrioid/gatsby-source-webdav

You can copy the other plugin into your plugins/ directory if you want to use it. I may release it on NPM later.

Configuring the plugins

gatsby-config.js (in your plugins section)

[
  {
    resolve: "@andrioid/gatsby-source-webdav"
      options: {
        baseURL: `https://${process.env["BLOGDATA_BASEURL"]}/remote.php/dav/files/${process.env["BLOGDATA_USER"]}`,
        credentials: {
          username: process.env["BLOGDATA_USER]",
          password: process.env["BLOGDATA_PASSWORD"], // Please don't hardcode this
		},
		recursive: true,
		glob: "**/*.{md,jpg,jpeg,png,gif}",
		sharePath: "Documents/MyVault/Blog", // yours will vary
      },
    },
    {
      resolve: "gatsby-transformer-remark",
      options: {
        plugins: [
          "gatsby-remark-webdav", // if you use it
		  "gatsby-remark-images"
        ],
      },
    },
]

When you start your Gatsby dev-server, make sure to add the ENV variables you just configured, like so:

BLOGDATA_BASEURL=https://mynextcloud.example.com \
BLOGDATA_USER=myuser \
BLOGDATA_PASSWORD=secret \
npm start

Gatsby will now connect to your Nextcloud server and process all the files listed in sharePath

Node Creation

What gatsby-source-webdav does, is creating Gatsby file nodes for the files it finds on the webdav endpoint. Then gatsby-transform-remark reacts to those file-nodes and creates markdown nodes.

If you're using my gatsby-remark-webdav plugin, then it reacts to webdav backed Markdown nodes and then copies the files necessary to link image

Those markdown nodes are then used to generate our blog posts or other markdown powered pages (and we won't be covering that).

Every Gatsby site is a bit different in how it creates pages, but I like to add node fields so that my GraphQL queries on pages are as simple as possible.

Here is my onCreateNode handler, yours may differ. What is happening here, is that some of my content is sourced from files, but some of it is sourced from webdav. To unify the node-fields, I use frontmatter where I can, but otherwise I try to use sensible defaults (like filename on webdav).

Note: Please don't copy this blindly. There are some things (such as the slug generation) that should be rewritten when I wrote this blog post. Hopefully I already did that at the time you read this.

gatsby-node.js

exports.onCreateNode = ({ node, getNode, actions, reporter }) => {
  const isDev = process.env.NODE_ENV !== "production";
  const { createNodeField } = actions;
  if (node.internal.type === `MarkdownRemark`) {
    if (!node.parent) {
      return;
    }
    const fileNode = getNode(node.parent);

    const { frontmatter } = node;
    let title = frontmatter.title;
    let slug = frontmatter && frontmatter.path;
    let date = frontmatter && frontmatter.date && new Date(frontmatter.date);
    let tags = (frontmatter && frontmatter.tags) || [];
    let draft = (frontmatter.draft === true && !isDev) || false;

    if (fileNode.parent) {
      const davNode = getNode(fileNode.parent);
      if (davNode && davNode.internal.type === "webdav") {
        const namePath = path.parse(davNode.filename);
        if (!title) {
          title = namePath.name;
        }
        if (!slug) {
          slug = `${namePath.dir}/${namePath.name}`.toLowerCase();
        }
        if (!date) {
          date = new Date(davNode.lastmod);
        }
      }
    }

    if (!slug) {
      console.error("no slug", node);
      //reporter.panic("No slug found for markdown node");
    }

    createNodeField({
      node,
      name: `title`,
      value: title,
    });

    createNodeField({
      node,
      name: `slug`,
      value: slug,
    });

    createNodeField({
      node,
      name: `date`,
      value: date,
    });

    createNodeField({
      node,
      name: `tags`,
      value: tags,
    });

    createNodeField({
      node,
      name: `draft`,
      value: draft,
    });
  }
};

Automating the process

I did mention that I don't want to think about publishing. The only thing I need to change to publish my blog-posts is to set draft: false in my frontmatter and it should just deploy.

What I really wanted to do, was to get Nextcloud to notify DigitalOcean (where I host my blog) and initiate a deployment from there. But, I couldn't get Nextcloud's Flow to work. If you know how to do it, please let me know.

Plan B

I settled on a less complicated solution. I use Github Actions to deploy my site every night.

Update. Github didn't like that much and changed how cron works for Github Actions..

You need to add DIGITALOCEAN_ACCESS_TOKEN and DIGITALOCEAN_APP_ID to your project's secrets. To create the acceess-token, follow these instructions.

.github/workflows/daily-deploy.yml

name: Daily Deploy
on:
  schedule:
    - cron: "0 3 * * *"
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Install doctl
        uses: digitalocean/action-doctl@v2
        with:
          token: ${{ secrets.DIGITALOCEAN_ACCESS_TOKEN }}
      # Force is used because we fetch from webdav
      - run: doctl apps create deployment ${{ secrets.DIGITALOCEAN_APP_ID }} --wait --force-rebuild

While I use DigitalOcean's App platform, there is nothing preventing this from working on other great hosting providers like Netlify or Vercel. But because we're sourcing our blog-posts from webdav, these Git based integrations have no way of knowing that our site now has new data.

Remember to add your Nextcloud credentials to whatever build-platform you're using. Otherwise you're not going to get any data from the webdav server.

Room for improvement

Slug generation

I really wanted to get this out there, so I haven't made the slug generation as pretty as I'd like.

Mermaid

Obsidian supports Mermaid diagrams, and I want my Gatsby site to render those as well. I tried using gatsby-remark-mermaid, but it didn't work with DigitalOcean's buildpacks due to a missing Chrome(ium) installation. That's one heck of a dependency, if you ask me.

I'll look into it later.

`gatsby-remark-webdav`

As I noted earlier, I just threw something together that works for me and if I find the time and motivation; I'd like to release it. Until then, grab it from here if you need it.

What's missing?

It's hard to compress my entire website into one article. I hope I covered what you need to set up something similar with your Gatsby site.

My site's source-code is on Github, so feel free to poke around there if something isn't working.

Let me know via DM if you think I should add something to this article.

Oh, and in case you were wondering. This blog post was written in Obsidian and automatically deployed.

Adding Progressive Web Apps (PWA) to the Linux Desktop (2025)

Fri, 02 Oct 2020 00:00:00 GMT

At work, we use Microsoft Teams, and we used to (and sort of still) use Slack. I recently switched from a Macbook Pro to a Linux laptop (again), and what annoys me greatly is that when I "share screen/application" in the Slack or Teams app it offers me only to share my entire monitor.

Chrome can do it!

By accident, I stumbled upon that Slack running in Chrome on Linux can share windows just fine. The native Slack app does not. So I went on an adventure to figure out how to add web-apps to the Linux desktop and it's surprisingly hard to find (hence this post).

As of 2025, this option is in "Menu -> Cast, Save & Share -> Install".

Just navigate to the site you want to open as an application, click "Create Shortcut" from the menu, check "Open as Window" and you're good.

On Linux, this will create a .desktop file in ~/.local/share/applications so that your desktop environment will pick it up. This guide should also work fine on Windows and Mac.

Note, that if you have Chrome installed via Flatpak, it might not have permissions to save the .desktop files. Use a tool like Flatseal to add ~/.local/share/applications and ~/.local/share/icons to filesystem permissions.

Plus, it's better!

Today, I'm running Outlook, Slack and Teams as progressive-web-applications and the performance is much better, screen/window sharing works and it uses less CPU than the Electron apps.

Desktop files

The application definition file looks something like this. You can technically create those yourself. Just make sure that the IDs are fresh.

#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Terminal=false
Type=Application
Name=andri.dk | Andri Óskarsson
Exec=flatpak 'run' '--command=/app/bin/chrome' 'com.google.Chrome' '--profile-directory=Default' '--app-id=mciljpmicooimcedlcgapdnklfobboeb'
Icon=chrome-mciljpmicooimcedlcgapdnklfobboeb-Default
StartupWMClass=crx_mciljpmicooimcedlcgapdnklfobboeb
X-Flatpak-Part-Of=com.google.Chrome
TryExec=/var/lib/flatpak/exports/bin/com.google.Chrome

Deploying a Full-Stack app on Google with Terraform

Thu, 18 Jun 2020 00:00:00 GMT

In this series, we are going to setup continuous deployment on Github Actions that will deploy a full environment in the cloud. Then we will setup a scheduled action to tear it all down, if we're not using it.

Part 1: Covers the infrastructure setup and backend
Part 2: Covers Github Actions

Note: While this is perfectly fine for development-environments, you should probably NOT do this in production.

Motivation

I didn't like paying for hosting on projects that I rarely have time to work on. So, I figured that if I could describe my environment decleratively, then I could just create automatically when I need it, and delete it automatically when I don't.

Before we begin

You will need a few things before we get started.

A Google Cloud account
A Google Cloud project
Terraform installed
A service-account with a JSON key file.
The following roles on your service-account: Cloud Build Service Account, Cloud Build Editor, Cloud SQL Admin, Editor, Service Account User, Cloud, Run Admin, Storage Admin

When you have the JSON key file, you can add it to an environmental variable while you work with Terraform. If you forget to add this to ENV, then Terraform won't be able to talk to GCP.

export GOOGLE_CREDENTIALS=$(cat ~/Downloads/path-to-my-secret-service-account.json)

Note: We are giving this service-account some pretty broad permissions on our project. So, be careful of not putting the file into Git or anything like that. I also recommend trimming these permissions manually.

Describing our environment

Hashicorp's Terraform is "infrastructure as code", or as I would put it: "A declaritive way of describing your hosting environment". Instead of telling Google or Amazon what to do, we tell Terraform how it should look like. Terraform then does the required API calls, and if everything is as it should be, it will do nothing at all.

This may seem overly complicated, but by doing this, copying an environment is trivial. If there's a new person on your team that wants to know what environments are running, we can look in one place.

We will be deploying:

a Postgres database
a storage bucket
a managed container with a Go backend

Initial Terraform configuration

Terraform configuration-files have a .tf postfix. To keep things simple, we'll only use one file (main.tf). The file is rather large, so we will start small and then add to it.

provider "google" {
  project = var.project
  region  = var.region
  version = "= 3.23"
}

This just tells Terraform that we'll be using the Google Cloud provider. We lock the version, so that our configuration file matches the provider API used.

Persisting our state

If you run Terraform locally, you might notice a .tfstate file. It tells Terraform which services are already created, their last known configuration and so on. We will be using Terraform as a part of our builds, so we want this state to be persisted somewhere globally.

To be able to do that, you need to manually create a bucket called tfstate.internal.example.com (or whatever you want, just make it match the configuration below) in your Google Cloud project.

terraform {
  backend "gcs" {
    bucket = "tfstate.internal.example.com"
    prefix = "terraform/state"
  }
}

Note: The Terraform state bucket cannot be managed by Terraform. You must create it yourself.

Variables

Using variables allow us to define stuff like "region" and "database_secret" in one place. Terraform variables can also be set using ENV, like "TF_VAR_REGION" will be matched to a "region" variable.

variable "region" {
  type        = string
  description = "GCP region"
  default     = "europe-west1"
}

variable "project" {
  type        = string
  description = "GCP project"
  default     = "example-project"
}

# Used by our non-root database user
variable "db_password" {
  type        = string
  description = "Database secret"
}

# Used by our deployment pipeline to set the new image.
variable "docker_tag" {
  type        = string
  description = "Tag for Docker Image"
  default     = "latest"
}

Adding the database

Since this is just a teeny tiny staging environment, we buy the cheapest database server around. We are using Postgres 11, there are also other database types and options.

Note: We will be destroying our database periodically, so if you need to store something permenently, you should do backups.

resource "google_sql_database_instance" "db" {
  name             = "db"
  region           = var.region
  database_version = "POSTGRES_11"
  settings {
    tier = "db-f1-micro"
  }
}

resource "google_sql_database" "dbname" {
  name     = "staging"
  instance = google_sql_database_instance.db.name
}

resource "google_sql_user" "dbuser" {
  name     = "pgadmin"
  instance = google_sql_database_instance.db.name
  password = var.db_password
}

You will notice that we are referencing our variables (like var.db_password), but we're also referencing the resources controlled by Terraform. In this case, we fetch the instance-name from the newly created instance. In a normal setup, we'd have to know this information to be able to proceed. By using Terraform, it manages all of these references for us.

Adding a storage bucket for assets

My application uses Go Cloud Development Kit to store assets. And on Google Cloud, that means adding a Cloud Storage bucket to the project. At the moment, this bucket is private. Check the documentation if you want a public bucket.

resource "google_storage_bucket" "assets" {
  name     = "assets.example.com"
  location = "EU"
  #force_destroy = true # If you want this destroyed when we take our environment down, uncomment this line
  bucket_policy_only = true
}

Adding a cloud-run service

This guide is not going to cover building Docker images or creating Dockerfiles. In the second part of this guide, we will build a docker-image, push it to Container Registry and pass it on to Cloud Run.

I was going to use Github Packages, but Cloud-Run only works from Google's Container Registry.

For demonstration purposes, we are just using a sample image from Google, and the ENV variables will not be used. But I spent quite some time digging up how to make the SQL connection work, so I think leaving it in will be helpful The metadata part tells the Google SQL Proxy how to connect to the database and how many instances we will allow Google to scale to.

resource "google_cloud_run_service" "backend" {
  name     = "backend"
  location = var.region

  template {
    spec {
      containers {
        image = "gcr.io/cloudrun/hello:${var.docker_tag}"
        # Demonstration purposes only
        env {
          name  = "PG_STRING"
          value = "host=/cloudsql/${google_sql_database_instance.db.connection_name} user=${google_sql_user.dbuser.name} password=${google_sql_user.dbuser.password} dbname=${google_sql_database.dbname.name} sslmode=require"
        }
        # Demonstration purposes only
        env {
          name  = "BUCKET"
          value = "gs://${google_storage_bucket.assets.name}"
        }
      }
    }

    metadata {
      annotations = {
        "autoscaling.knative.dev/maxScale"      = "3"
        "run.googleapis.com/cloudsql-instances" = "${var.project}:${var.region}:${google_sql_database_instance.db.name}"
        "run.googleapis.com/client-name"        = "terraform"
      }
    }
  }

  autogenerate_revision_name = true
}

Custom name for your Cloud Run instance

Google offers automatic TLS and load balancing with custom-names. First you have to validate your domain with Google, and then you have to add your service-account to it.

When that is done, you can use the following to add a custom dns name.

# https://cloud.google.com/run/docs/mapping-custom-domains#adding_verified_domain_owners_to_other_users_or_service_accounts
resource "google_cloud_run_domain_mapping" "backend" {
  location = var.region
  name     = "api.example.com"

  metadata {
    namespace = var.project
  }

  spec {
    route_name = google_cloud_run_service.backend.name
  }
}

Terraform Plan

Navigate to your directory. I keep mine in devops/google/main.tf.

terraform plan

Terraform Apply

If you agree with the changes suggested by terraform plan you can run:

terraform apply

Terraform Destroy

To clean up all the resources we have created, we can run:

terraform destroy

Note: I don't take any responsibility for what you might leave on your account. So make sure that the cleanup worked as expected.

Part 2: Setting this up on Github Actions.

I'll add a link to the second part of this blog post as soon as it's ready.

Meetings from Home: Tools

Mon, 16 Mar 2020 00:00:00 GMT

Are you working from home? Here's a list of some great tools that you can use for free.

If you have anything to add to the list, please give me a shout at @andrioid.

Video Conferencing and chat

Jitsi Meet

Not quite as polished as some of the commercial options, but quite capable. Works best with Chrome, but seemed to work fine in Firefox too.

No account required: ✅
No organization required: ✅
Open Source: ✅
Self Hostable: ✅
Screen Sharing: ✅
Chat: ✅

Team.video

Does exactly what the names says. No account required, very simple to use.

No account required: ✅
No organization required: ✅
Open Source: 🚫
Self Hostable: 🚫
Screen Sharing: ✅
Chat: ✅

Whereby (formerly Appear.in)

Used to be my favourite video-conferencing tool.

No account required: 🚫
No organization required: ✅
Open Source: 🚫
Self Hostable: 🚫
Screen Sharing: ✅
Chat: ✅

Slack

Needs no introduction. A chat app that also has voice and video features.

No account required: 🚫
No organization required: 🚫
Open Source: 🚫
Self Hostable: 🚫
Screen Sharing: ✅
Chat: ✅

Microsoft Teams

Microsoft's answer to Slack. Needs your organization to have a Microsoft account and the Teams feature activated.

No account required: 🚫
No organization required: 🚫
Open Source: 🚫
Self Hostable: 🚫
Screen Sharing: ✅
Chat: ✅

OpenVidu

Free, but you have to host it yourself or pay for it. Has multiple types of rooms.

No account required: 🚫
No organization required: 🚫
Open Source: ✅
Self Hostable: ✅
Screen Sharing: ✅
Chat: ✅

BigBlueButton

More focused on teaching than meetings. Integrates to learning-systems. You need to host it yourself or pay for the hosting.

No account required: 🚫
No organization required: 🚫
Open Source: ✅
Self Hostable: ✅
Screen Sharing: ✅
Chat: ✅

Whiteboarding

Excalidraw

An excellent tool that makes it quite easy to draw diagrams or simple drawings.

Diagrams: ✅
Live collaboration: ✅
Free form: 🚫

2019 in Tech

Sun, 29 Dec 2019 00:00:00 GMT

Every year, or that was my plan back in 2013; I do a review of what technology I've been using during the year and reflect on my experiences.

This year has been fun in many ways. I have been creating apps, websites, microservices and APIs.

React

When I started playing with React 4 years ago, Angular was insanely popular in Denmark and everyone was looking at me funny. There was no standard tool for anything and every week there were major version changes in the stack.

I heard this somewhere:

People use Angular because of Google. People use React even if Facebook made it.

Today, I look back on React with fondness. I started making web-sites back when we had .shtml files and .php3. But then something changed. We as an industry started using the browser for more than rendering markup and then we had a few broken years.

The core problem, as I see it; is that we no longer have enough information to fully generate web-pages on the server anymore. The users expect a certain amount of dynamic functionality and while it isn't hard to add small snippets, this quickly becomes unmaintainable.

Some people realized this and tried to combine one templating language for both server and client. But as soon as the initial data started to change, there were issues.

React changed all of this. We now have one language to describe UI as a function of props and state. I can't imagine doing UI any other way. It might be Svelte or Vue in the future; but components are here to stay.

Go, the programming language

I'm sure some people consider me an early adopter, but I had my eye on Go for a very long time before I started using it professionally 3 years ago.

It's funny how I can be excited for a language that has very few features, roughly 6 years after I first started playing around with it.

It feels like being on the same team. We all use the same formatting, the standard library usually has the functionality we need and there is less friction when working with others. This contributes to what I consider to be a very productive language.

In 2019 I have created GraphQL API's, microservices and small tools and Go is by far my favourite backend language.

TypeScript

In May, I joined a new company and they were doing all of their new code in TypeScript. The project I joined has alwaysStrict=true and I hated it very much. Everything I was used to do in JavaScript was now something that the compiler refused to make work. I spent 2/3 of the time defining types for something I thought was obvious.

Later, I moved to another project where we also did TypeScript with React, but without strict-mode this time. This time, it clicked for me. It helped that I had 6 months experience with TypeScript at the time, but being free to use TypeScript without the feeling that I was being used by it.

Bottom line. Would I use TypeScript again? Yes. Being able to define types for props and state really speeds up development. Strict-mode? It's too verbose and results in some very ugly code without any good reason.

Immer

I first heard about Immer over at React Europe 2018, in the context of being "better than Immutable.js", but I had absolutely no intention of doing anything, that changed all of my state data to some weird types again. So I ignored it.

Then, I was dealing with some internal state in React that included messing with items of an array. Arrays in React state is probably the most annoying part of React. It feels verbose and hard to read at the same time. This immutable dance with arrays is painful; even in modern JS or TS.

Immer is lovely. It's a function that takes the current state, gives you a "draft-state" that you can mutate. Then it produces a new output and returns it. The best part

So you can simply do

import produce from "immer";
const [animals, setAnimals] = useState(["Cock", "Raven", "Dog", "Pig"]);
setAnimals(
  produce((draftAnimals) => {
    draftAnimals[0] = "Rooster";
  }),
);

This will produce a new array with the changes applied and React will render the changes as expected.

Immer is a must-have tool in your React toolbox.

React Native

I used to work at a company that does mobile-payments for parking. They had an app that was once a nice Xamarin application that worked on iOS and Android. But after 2 years of out-sourcing the app was unstable and unmaintainable (we spent 4 months on just making it stop crashing, without luck). I was responsible for the project and I had a feeling in my stomach that this was probably never going to be ok unless we'd invest an entire team into this.

I had tried playing with React Native when 2 years earlier, when they released initial support for Android, but it didn't feel mature at all. So, I decided to give it another shot and spent a few evenings and a weekend making a simple proof-of-concept in React Native. Long story short: I pitched it to my boss and we created a new app in React Native and Expo.

Expo was a really positive experience for me. I didn't have a big team, so being able to skip the native part of React Native was a clear win for me. All of the libraries we needed were already in Expo, so it was a no-brainer.

So when I started on a new React Native project this year, where we had to do all of the native parts ourselves, I was a bit scared. To my surprise, it wasn't as hard as I thought. I managed to do some minor changes to a Swift library without knowing anything about Swift or Xcode with help from my co-workers. And making the native bits talk to the JS bits was quite simple too.

All in all, a positive experience. Would do again.

For 2020?

I'm starting the year with by joining an existing React Native team and I'm looking forward to help bring the project forward.

So here's hoping for another year filled with good technology. I wish you a happy new year!

Announcing gatsby-plugin-social-cards

Sun, 15 Sep 2019 00:00:00 GMT

Ever seen those images shown next to posts on Twitter, Slack or Facebook? Ever wonder where they come from? Me too!

This plugin will create automatic cards for your (ReMark) at build-time.

Announcing

I am ready to announce my new Gatsby plugin, gatsby-plugin-social-cards.

There are a few alternatives for Gatsby social-cards, but I wanted to try making these cards with SVG, React and the Sharp library that most Gatsby sites already depend on.

Currently this plugin resides within my site, but if there is interest in it, I'll move it into its own repo. Contact me on Twitter if you have any issues.

Features

Backgrounds

You can put a cover frontmatter on your post, and we'll use that. Otherwise, we'll use a default-background that you can specify or if that fails, we'll use a fallback one.

Designs

There are two design available now, "card" and "default". But we can expand that later.

Author image

If specified, an author image is shown on the image. That is also configurable.

Custom author-image

The author image can be ommitted if it's not wanted, or customized in the configuration.

Install

yarn add gatsby-plugin-social-cards
# or npm install --save gatsby-plugin-social-cards

How to use

Please see the README for how to use.

Slim Docker images for your Go application

Fri, 06 Sep 2019 00:00:00 GMT

How to build a slim Docker container for your Go application using multi-stage images.

I'm using Go 1.13 and the community module proxy to build the binary and Alpine as a base image. It adds a user and group instead of running as root.

Dockerfile

Be sure to replace "cmd/server/server.go" with your main file.

FROM golang:1.13 as builder

WORKDIR /app
COPY . /app
RUN CGO_ENABLED=0 GOOS=linux GOPROXY=https://proxy.golang.org go build -o app cmd/server/server.go

FROM alpine:latest
# mailcap adds mime detection and ca-certificates help with TLS (basic stuff)
RUN apk --no-cache add ca-certificates mailcap && addgroup -S app && adduser -S app -G app
USER app
WORKDIR /app
COPY --from=builder /app/app .
ENTRYPOINT [ "./app" ]

I hope this is helpful. I mostly blogged this to document it for myself.

Making a Gatsby site from Meetup event data

Sun, 25 Aug 2019 00:00:00 GMT

As part of my talk preperation for Aalborg Frontend Meetup, I was going to do a walkthrough of a new Gatsby site and use gatsby-source-meetup to import the upcoming events.

Imagine my surprise, when I discovered that Meetup had stopped issuing API keys.

gatsby-source-ical

Gatsby has a wonderful collection of source plugins, and one of them happens to be gatsby-source-ical. I'll hand it to Meetup support; they did send me a useful link that indicated they I may not need an API, since they have a calendar feed available.

Finding the calendar export

First, find your group on Meetup, click "Events", "Calendar" and at the bottom there are feed links (if you're logged in).

For our group, the URL is: "https://www.meetup.com/Aalborg-Frontend/events/ical/"

Add the plugin

yarn add gatsby-source-ical

gatsby-config.js

// In your gatsby-config.js
module.exports = {
  plugins: [
    // You can have multiple instances of this plugin
    // to read source nodes from different remote files
    {
      resolve: `gatsby-source-ical`,
      options: {
        name: `events`,
        url: `https://web-standards.ru/calendar.ics`,
      },
    },
  ],
};

Query the data

{
	allIcal {
		edges {
			node {
				start
				end
				summary
			}
		}
	}
}

Why?

I put this together in case someone else is creating a meetup website with Gatsby and got frustrated with the API change.

Choosing a programming language

Sun, 04 Aug 2019 00:00:00 GMT

Imagine that you're a CTO, a Tech Lead or someone that has to make an early technical decision that will effect the company for years to come. What programming language do you choose?

The cost of abstraction

Systems tend to have two types of complexity. Complexity from the business-domain, and complexity from the technical-domain. In my experience, the technical-complexity takes up more room than it should.

There are, of course brilliant programmers out there, who manage complexity really well, regardless of what language they code in. But people have different skill-sets, and a great team has many different types of members.

Readability

When I took my first programming job, I was looking forward to "writing some awesome code". But, writing code wasn't my primary job. Reading it was.

There are some tools that help manage this. Coding-standards, linters, code-formatters all try to make reading each other's code easier.

But what if every feature of our programming language, comes with a cost? If you give 10 programmers the same task, how similar would the implementations be? I argue that if you get many different types of implementations, then your programming language is too complex.

To be productive at writing code, we also need to be productive at reading it.

Dependencies

At a certain point we need something from our programming language that isn't a language-feature, but a library feature. We need to open a file, parse HTTP headers, decode JSON, or talk to databases.

Every dependency we add to our programs comes with a price, even if the code is free. What if the maintainer get's hit by a bus? What if the maintainer becomes malicious? What if there's a critical security bug?

Why did PHP win over Perl for web-development in the late 90's? I'm willing to bet it was because PHP's standard-library was so good, and well documented.

Another approach is Javascript's NPM where there is no standard library. Every little thing has it's own package. The advantage has been that the community of JS really stepped up and you can find a package for any thing you can imagine. The disadvantage is that with nested dependencies, we have no idea on what code we're actually depending on. There hasn't been a NPM apocalypse yet, just the story of left-pad and an occasional bitcoin miner.

I think this a no-brainer. If we're building something that needs to be reliable for years to come, then we need a standard library that has security updates and advisories when shit happens. And remember, that we don't include dependencies, we adopt them.

Hiring people

At some point, we all need help. And that help usually comes to us by means of hiring people. If it wasn't for this point, I might be programming in Erlang, Elixir and Elm right now. I think these languages are extremely interesting, and not just because they all start with the letter E.

But reality sets in, and we need a pool of people to hire from, that either know your tech-stack or will have an easy time learning it.

The exception is when an organization has decided to invest in something, has a resources to teach newcomers and is willing to pay premium for talent.

Performance

Performance is important. But, aim for "good enough" instead of "perfect". "Perfect" will almost certainily have a downside in other parts of this post.

Does your project require some hard-core performance? Systems that have a "hard" real-time requirement might limit your choices. "Soft" real-time is still doable in almost any language.

We once programmed in a world of a single CPU. That world is no more. Please pick a langauge that handles multiple executions well.

A practical example would be a checkout-API call on a webshop. The customer has submitted a payment token, an order, and an email we need to verify. None of these things depend on each other, but all three things need to complete to succeed.

Developer Experience

To me, a good developer experience consists of the following things.

The code is easy to read and understand.
The language is supported in my editor (or IDE) of choice.
There is a good, reliable debugger available.
Easy to write and run tests, both locally and in build-systems.

Final words

We try to plan for the future, but nobody really knows it will bring. So, aim for the next 5 years and then time will tell.

What language would you pick, and why?

Creating a CV in React

Mon, 22 Jul 2019 00:00:00 GMT

TLDR;

But why?

I never much cared for pixel-pushing on screen. It has always been a necessary evil. But, print? Love that shit. I did my university reports in LaTeX, even the graphics and even though the errors were HORRIBLE, it remained a loyal TeX fan.

So when I received a task at work to evaluate react-pdf vs CSS-printing I knew I had something special to play with.

I wanted the following features:

Use JSON resume for the CV data
Components for for work-experience, education and sections
Built automatically with my Gatsby site into a PDF file

A good starting point

There is a an example in the react-pdf repo that has much prettier code then mine. So, if you want to make your own, I suggest you start there.

Using JSON resume, well mostly

If you're anything like me, you don't like updating your CV, or portfolio. Or you just forget. We can use one JSON file for all those things and be done with it.

The spec is good, but I made some minor changes to mine. I added a "skills" array to work-item and "color" string to skill-items.

Visit jsonresume.org and make your own resume.json file.

They even offer free hosting and rendering of your résumé, and if you're feeling lazy, then just do that instead.

Components

I've pasted some code in here, so that you can get a little feeling for how this is built. But, keep in mind that the code might change, and refer to the repo for code-examples.

Box

A simple box, with an headline.

export const Box = ({ children, title, color, style = {} }) => (
  <View wrap={false} style={{ marginBottom: 20 }}>
    <SectionHeader color={color}>{title}</SectionHeader>
    <View style={{ ...style }}>
      {children && typeof children === "string" ? (
        <Text>{children}</Text>
      ) : (
        children
      )}
    </View>
  </View>
);

Work Item

export const TimelineItem = ({
  title,
  period,
  children,
  employer,
  tags = [],
  location,
}) => {
  tags = tags.sort();
  return (
    <View wrap={false} style={{ marginBottom: 10 }}>
      <View
        style={{
          flexDirection: "row",
          justifyContent: "space-between",
          marginBottom: 2.5,
          flexWrap: "wrap",
        }}
      >
        <Text style={{ fontWeight: "bold" }}>
          {title}, <Text style={{ fontWeight: "normal" }}>{employer}</Text>
        </Text>
        <Text>{period}</Text>
      </View>

      {children && <Text style={{ marginBottom: 2.5 }}>{children}</Text>}
      {tags && (
        <View style={{ flexDirection: "row" }}>
          {tags &&
            tags.map((m) => (
              <Tag key={m} color={tagColors[m.toLowerCase()]}>
                {m}
              </Tag>
            ))}
        </View>
      )}
    </View>
  );
};

Build with Gatsby

Originally, I wanted Gatsby to render my CV as a page, using react-dom on the client and pdf on the server. That turned out to be very hard to do, with little gain. So now we just generate the PDF file seperately.

In retrospect, I should probably move this into pkg/cv instead of src/cv.

package.json

	"scripts": {
		"build-cv": "cd src/cv && babel-node build.js",
		"watch-cv": "cd src/cv && nodemon --exec babel-node build.js"
	},

gatsby-config.js

exports.onPostBuild = () => {
  const cp = require("child_process");
  cp.execSync("yarn run build-cv");
};

src/cv/.babelrc

From the react-pdf repo. I also tried to adapt Gatsby's babel configuration here, but without luck.

{
	"presets": [
		[
			"@babel/preset-env",
			{
				"loose": true,
				"targets": {
					"node": "current"
				}
			}
		],
		"@babel/preset-react"
	],
	"plugins": [
		"@babel/plugin-transform-runtime",
		"@babel/plugin-proposal-class-properties"
	]
}

Workflow

Then just run yarn run watch-cv while developing it. I use evince on Linux as my PDF viewer, because it automatically reloads the file on-write. So almost like hot-reloading.

Conclusion

This was a fun project for me. I'm not seeking employment, so I'm not motivated to polish it further at this time. I hope this gave a few bread-crumbs, if you're considering something similar.

Breaking the silence

Sat, 06 Jul 2019 00:00:00 GMT

As you can see from my frontpage, I haven't blogged since 2014. Sorry about that.

I'm learning new things while building this site, again again. It's currently running on Gatsby with Tailwind-CSS, GraphQL and a few plugins.

I'm also playing around with react-pdf and JSON-Resume. My CV is currently generated with the site and I plan to make the site, and the CV fetch data from my resume.json.

2013 Tech Stack

Fri, 03 Jan 2014 08:19:54 GMT

As I do pretty much, every year. 2013 was spent learning new technologies. Here's a short list.

Go: I taught myself a little bit of Golang and made a few small prototypes in it. I love the language so far, and while it is a bit restrictive, it's for my own good, as the code is easier to handle.
PostgreSQL: While a pain in the ass to setup, pgsql is an awesome database and with HSTORE and JSON data types, it can also be used as a key/value storage. I am mostly using it to replace MySQL in some pet projects.
KnockoutJS: A declarative JS library that makes it possible to create rich applications without dealing too much with markup. I have been using it for a small project that deals with nesting templates in a tree.
Redis: A fast, distributed key/value database that I was using for a small prototype dashboard project. Especially the queue features are nice, although I wouldn't use this as a persistent storage.
D3js: Create SVG diagrams from data. I was also experimenting with D3 for my dashboard project and while I can't say that I am 100% comfortable with it, it is extremely powerful.
Java: Most people learn Java early, but not me. I spent 3 months at a new job programming Java and I must say that I like the language, although I hate the toolkit.
Docker: Absolutely a game-changer in 2013. Docker allows you to create containers for your applications that you can use for development, testing and eventually production without encumbering you with virtual machines. I've been using it for development and hope to do more soon.

I am probably forgetting something, but these are the highlights of 2013. I look forward to playing with even more new stuff in 2014.