Blog — Sam Zanca

Stop choosing Convenience

Sun, 05 Jul 2026 04:41:21 GMT

For years, I've been frustrated by the number of desktop apps companies ship using Electron. I understand why Electron became popular. It gave us a simple way to build cross-platform desktop applications, let frontend developers reuse their existing React skills, and kept the development experience familiar.

But we're in a different era now. We're in the AI era.

Companies are encouraging developers to use AI coding agents, and that's changing the tradeoffs around software development.

I've noticed this trend outside of desktop development too. On Twitter, I've seen developers moving away from clever abstractions and compact libraries in favor of more explicit code because AI models are simply better at working with it.

Take React as an example. We used Redux everywhere for years. Then the industry moved away from it because it was considered too verbose, replacing it with Zustand, custom hooks, and countless homegrown state management solutions. Every company seemed to reinvent the wheel a little differently.

Today, Redux doesn't seem quite so unreasonable anymore.

Its patterns are well established, predictable, and explicit. Those are exactly the kinds of codebases AI thrives in. AI is effectively averaging millions of public GitHub repositories. If we write software using patterns that are consistent across companies and skill levels, AI has a much better chance of producing the correct result.

I think desktop development is in a similar position.

If we're already relying on AI to generate large portions of our applications, why are we still optimizing for Electron's biggest advantage? The original selling point was that frontend developers didn't have to learn native desktop development. But if AI is doing most of the implementation work, that advantage becomes much less important.

Instead, why not build better desktop applications?

The framework I've become most interested in is GPUI from the Zed team. Yes, it's Rust, and Rust isn't an easy language. But GPUI's architecture feels surprisingly familiar to anyone who's written React before. Combined with modern AI models, it's much more approachable than I expected.

I've one-shotted several GPUI applications using DeepSeek V4 Pro, which is hardly the most expensive model available. The framework is surprisingly productive because it gives you a solid foundation without requiring a massive amount of code.

The biggest thing holding GPUI back isn't developer experience. It's the ecosystem.

For example, video support is still fairly immature. There isn't a widely adopted package that solves it cleanly, so many developers end up building their own solutions. Elliott from Dreams of Code implemented an entire video pipeline for Kiru. There are plenty of similar examples on GitHub using GPUI alongside wgpu or other Rust multimedia libraries.

That's normal for a young ecosystem. It will improve over time.

When it does, I think we'll have a compelling alternative to Electron.

Electron has become the default answer for desktop applications because it's convenient. But convenience comes with a cost. Every Electron application ships its own browser runtime, consumes more memory than it needs to, and contributes to the growing feeling that modern desktop software is becoming heavier every year.

If more of these applications were built with frameworks like GPUI, we'd end up with software that's faster, lighter, and makes much better use of system resources.

The thing that finally pushed me to write this was installing Whisper Flow.

Overall, I like it. The self-correction is genuinely impressive. I haven't used another voice-to-text system that cleans up spoken mistakes nearly as well.

For comparison, I currently use FUTO Keyboard on Android. It's good, but it's nowhere near Whisper Flow's quality. If I stumble over my words, FUTO faithfully transcribes the mistake. Whisper Flow often understands what I meant and quietly fixes it. That's a fantastic user experience.

But then I looked at the application itself.

It's an Electron app.

Why?

At its core, it's a push-to-talk application with speech processing. The heavy lifting is already happening inside Whisper. The UI is mostly a small settings window. It doesn't feel like an application that needs an embedded Chromium instance.

If anything, the performance-sensitive parts would benefit from being written in a lower-level language.

This feels like the perfect kind of application for GPUI or another lightweight native framework. Keep the interface simple, run Whisper locally, work completely offline, and ship something that's fast by default instead of carrying around an entire browser just to display a settings panel.

That's what made me realize something.

Electron solved a very real problem for the industry. But AI is changing what that problem looks like.

Maybe it's time to stop assuming Electron is the default choice and start building native desktop applications again.

How I setup my SolidStart apps

Tue, 30 Dec 2025 19:40:21 GMT

As of writing this, running bun create solid doesn't use the latest version, so we'll use bunx create-solid@latest.

In this quick guide I'll setup my preferred way to use solidjs/solidstart. Preferring to use a guide such that I don't have to maintain a template over time.

Starting with the drizzle template

bash

bunx create-solid@latest -s --ts -t="with-drizzle"

-s to make this a solidstart project, --ts to use typescript, -t="with-drizzle" to use the drizzle template

Update the .gitignore to ignore some files.

bash

# Other lock files (we're using bun)
package-lock.json
yarn.lock
pnpm-lock.yaml

# sqlite file
drizzle/db.sqlite

Add this convenience dev script to the package.json. This will wipe the db, push the schema and start the dev server.

diff

"scripts": {
+  "dev:fresh": "rm drizzle/db.sqlite && drizzle-kit push && vinxi dev
}

Change the Drizzle driver to `libsql`

We're swapping out drizzle's built in better-sqlite3 driver, which requires a custom dockerfile when deploying to railway for libsql from turso which is pure javascript. No idea what the trade-offs are but this makes my side projects easier to deploy.

bash

bun rm @types/better-sqlite3
bun add @libsql/client

diff

// drizzle.config.ts
export default {
  dialect: "sqlite",
  schema: "./drizzle/schema.ts",
  out: "./drizzle/migrations/",
- // driver: "better-sqlite",
  dbCredentials: {
-   url: './drizzle/db.sqlite',
+   url: "file:./drizzle/db.sqlite",
  },
};

// src/api/db.ts
import { drizzle } from "drizzle-orm/libsql";
import { createClient } from "@libsql/client";
import { dirname, resolve } from "path";
import { existsSync, mkdirSync } from "fs";

// Use environment variable for database path, or resolve relative to project root
const dbPath = process.env.DATABASE_PATH
  ? resolve(process.env.DATABASE_PATH)
  : resolve(process.cwd(), "drizzle", "db.sqlite");
const dbDir = dirname(dbPath);

// Ensure the directory exists before creating the client
if (!existsSync(dbDir)) {
  mkdirSync(dbDir, { recursive: true });
}

const client = createClient({
  url: `file:${dbPath}`,
});

export const db = drizzle(client);

Add tailwind

bash

bun add solid-motionone @tailwindcss/vite
bun add -D tailwindcss

// tailwind.config.js
/** @type {import('tailwindcss').Config} */
export default {
  content: [
    "./src/**/*.{ts,tsx}",
  ],
  darkMode: 'class',
  theme: {
    extend: {},
  },
  plugins: [],
}

diff

# app.config.ts
import { defineConfig } from "@solidjs/start/config";
+import tailwindcss from "@tailwindcss/vite";

export default defineConfig({
  vite: {
    ssr: { external: ["drizzle-orm"] },
+    plugins: [tailwindcss()],
  },
});

Notes

The server entry file src/entry-server.tsx is a good place to start background tasks or server setup tasks. In dev, this runs once a route is hit but in prod this runs on server startup.

Tail-Call Optimization (in gleam)

Tue, 02 Sep 2025 16:15:33 GMT

Tail-Call Optimization is compiler optimization that allows a recursive function, where the last line of the function is the call to itself, to reuse the same memory stack, thus allowing the recursive function to use constant memory.

proof: Specification and Transformation of Programs by Helmut A. Partsch; Chapter 6

Why does this matter?

Tail-Call Optimization is crucial for recursive algorithms, especially those that might involve deep recursion. It prevents "stack overflow" errors by reusing the call stack for tail calls, ensuring constant memory usage. This makes highly recursive functional code robust and performant, avoiding crashes and allowing elegant solutions that might otherwise require iterative rewrites.

Feels Like Mutation (But Isn't)

In functional programming, mutation is typically avoided. However, by using accumulators in tail-recursive functions it can feel like to mutable state. The accumulator parameters effectively "store" the evolving state of the computation. With each recursive call, new values for these accumulators are passed, creating a new "snapshot" of the state rather than directly altering an existing variable. With TCO, we maintain immutability and get simpler code as a side effect.

The only negative in Gleam is you'll have to make a public facing wrapper function to hide the accumulator parameters since Gleam doesn't support optional or default arguments.

Example

Every recursive function can be turned into a tail-recursive one. So lets start with a classic example of Fibonacci, since its often used to explain recursion and we usually see it in its non tail-recursive form.

rust

fn fibonacci(n: Int) -> Int {
  case n {
    0 -> 0
    1 -> 1
    _ -> fibonacci(n - 1) + fibonacci(n - 2)
  }
}

To make it tail-recursive, we need to make sure the last call is a single call, not two. If you think about how a human would solve this, they would go in pairs of two: 0 + 1 is 1. 1 + 1, is 2, 1 + 2 is 3, 2 + 3 is 5. So lets add 2 accumulator values to keep track of our pairs.

rust

// Private, actual tail recursive function
fn fibonacci_tail(n: Int, a: Int, b: Int) -> Int {
  case n {
    0 -> a
    1 -> b
    _ -> fibonacci_tail(n - 1, b, a + b)
  }
}

// Public interface that simplifies the parameters
pub fn fibonacci(n: Int) -> Int {
  fibonacci_tail(n, 0, 1)
}

rust

// Both function the same
pub fn main() {
  10
  |> fibonacci
  |> echo // 55
}

Here's all the fibonacci_tail calls. As you can see a and b are basically holding all the fibonacci digits and slowly stepping thru the sequence.

rust

fibonacci_tail(10, 0, 1)
fibonacci_tail(9, 1, 1)
fibonacci_tail(8, 1, 2)
fibonacci_tail(7, 2, 3)
fibonacci_tail(6, 3, 5)
fibonacci_tail(5, 5, 8)
fibonacci_tail(4, 8, 13)
fibonacci_tail(3, 13, 21)
fibonacci_tail(2, 21, 34)
fibonacci_tail(1, 34, 55)
55

And here's a javascript version using an iterative approach.

function fibonacciIterative(n) {
  if (n === 0 || n === 1) return n;

  let a = 0, b = 1;
  for (let i = 2; i <= n; i++) {
    let temp = a + b;
    a = b;
    b = temp;
  }

  return b;
}

I don't know about you, but the gleam version is a lot easier to read and understand.

TODO add more examples

Compiler Support for TCO

TCO isn't universally supported. Languages like Gleam, OCaml, and Haskell offer TCO guarantees.

Conversely, many languages, including JavaScript, don't optimize tail calls by default. This can lead to stack overflows for deep recursion, unlike in languages with TCO. Always confirm your language and compiler's TCO support.

How I use Fish Shell

Fri, 29 Aug 2025 12:06:51 GMT

Tired of endlessly tweaking your shell configuration? Fish offers a refreshingly opinionated and powerful experience right out of the box.

I love the Fish shell for several reasons, the first being the out-of-box experience is best in class. You don't need to go crazy with plugins or hell even a status line tool like oh-my-zsh. You can just get to work. Fish comes with so many nice features that make moving around in the terminal so pleasant.

[!example]- To name a few

Caveat: Nushell is very compelling too as it has very comparable UX to Fish, but fish is a more familiar shell. Nushell completely changes the paradigm and offers features that might not interest you. Worth noting that both Nu and Fish have their own shell language.

Another reason is configuration. Yes, Fish has its own scripting language which makes it not POSIX compliant. Most make this out to be a bigger deal than it actually is. People complain about it being a poor choice for scripting and issues with portability. The solution to both of these, is to use fish-lang for only its designed purpose.

System-level scripts should be written in sh/bash for portability. Your shell config is personal.

As for integrating with tools most tools out there have fish integrations, so using fish is almost never actually an issue. Tools like python virtual environments create activate scripts in fish if that's the shell they detect you using. And if you're using a tool written entirely in bash you have two options:

Additionally, if you don't want a complex config, you can use the command fish_config which will give you a web-ui for customizing: themes, prompt, functions, and keybindings in a jiffy. This lets you get up and running with fish even faster.

Autocomplete

I just want to show a quick example of fish's game changing auto-complete.

Say you were to try this command in git:

bash

# First some setup
git checkout -b something-foo-bar-spike-feature-final;
git checkout main;
# Try this in bash, zsh, and fish
git checkout spike # press tab after spike

Only fish will give you an autocomplete result (out of the box). Because unlike bash and zsh, fish will fuzzy find and has built-in git integration.

General practices

All my fish configs are written in such a way that I make no assumptions about what is installed. This is both so that each machine can be using all or none of my preferred apps and I still get access to my fish config. Before I use any command/app/tool, I check that it exists.

bash

if type -q some_command
    # Configure some_command
end

My configuration

I got tired of having to be careful not to commit things that were appended to my fish config file, so I decided I'd move it to the conf.d directory.

from: $HOME/.config/fish/config.fish
to:   $HOME/.config/fish/config.d/config.fish

Turns out conf.d is loaded before the main config file anyways, so this changes basically nothing.

bash

├── conf.d/
│   └── config.fish
└── config.fish # This file is gitignored

As a result now the default config file can remain as a local config file. Any tool that wants to append things can do so and I don't have to care.

At any time I can look at my local config and move some of those into a conf.d file.

conf.d directory

This is a feature of Fish, so you don't need to source this folder or anything. This directory contains specific tool/app configurations. This keeps my config file more specific to shell configurations.

Generally, if a tool appends a blob of code to my config file, that's a good candidate for something to go into a separate conf.d file. So another way of viewing files besides config.fish, is that they're all code-gen'd. Where as config.fish is code I've written.

functions

Another great feature of fish, each file named after a command is a sort of lazy-evaluated script. All files here are only loaded when the function is called. So e.g. if I never uses bass, it'll never be evaluated.

Command line tools I use with Fish

More details https://github.com/metruzanca/dotfiles/tree/master/home/.config/fish

I use starship.rs as my status line. Starship has very similar opinions to fish. The out-of-box experience is superb and configuration is very simple.

I use zoxide as an improved cd which lets me just teleport to places I've previously been to.

I use lsd as a fancy ls replacement. And I hook into fish's fish_prompt event to call ls after changing directories so I always get a list as I move (which eliminates most calls of lsd).

My prompt starts up with pfetch because its pretty.

How to close the current window with JavaScript

Sun, 22 Sep 2024 16:03:18 GMT

[!example] tldr
js
window.open(location, '_self').close();
// or
window.close('', '_parent', '');
Working as of Chromium: 128.0.6613.138

Today I learned a little quirk with closing the current tab/window with Javascript.

So apparently, you cannot use window.close(); to close the current window, unless that window was programmatically opened. But you can close children windows if you kept a reference to them. As it turns out, the children can also close the parent window. And for some reason, if you call window.close('', '_parent', ''), this actually works.... but it shouldn't.

close doesn't actually take any arguments... (also see mdn)

Reading the html spec, close doesn't have args either.

Searching the internet, the only thing I could find was this post by natclark.

Apparently _parent, much like the widely known _blank has to do with a tag targets. There's actually more targets i.e.: _self, and _top.

Here's an interesting graphic explaining the targets from stackoverflow.

My best guess, is that this works purely for backwards compatibility. There's even a post talking about a similar workaround/exploit where you can call: window.open(location, '_self').close() that seems like it worked the same way.

I believe, that close takes arguments for backwards compatibility purposes, but the arguments are deprecated, so they're not documented anymore. So if browsers lost this ability, you couldn't blame them since its not in the docs.

window.close('', '_parent', '') seems to work because close tries to get the parent of the current window, finds that it is the top parent, so it then closes it's parent aka itself. Honestly, kind of strange still, the other workaround makes more sense.

window.open(location, '_self').close(): on the other hand, tries to open a window, but since _self already exists, then it gets reused and then we can call close on it, but since it was "opened" via Javascript, it no longer is blocked.

7.2.2.1 Opening and closing windows

[...] If a window already exists with that name, it is reused.

Both workarounds seem to work in Chromium: 128.0.6613.138 (Official Build) (64-bit).

Repeat yourself, dammit!

Fri, 05 Apr 2024 15:13:00 GMT

Dry is Dead and we Killed it.

Stop using DRY or making everything into a component/function. DRY leads to complexity. Sure, there might be less of it, but theres a higher density of complexity. I'd rather have more code, that is simple.

One of my favorite scenarios: having like 3 different wrappers of 1 tool. What if instead we didn't write a wrapper and just used the tool raw? Thats way less code, and way less complex since we didn't have to constantly add features to the wrapper to re-expose features of the original tool. And if we need to know how to use the tool, you've got plenty of examples of that vs one really convoluted and generic-ified usage of it.

We should instead use WET(write everything twice/thrice) or AHA(avoid hasty abstractions). Another way to put it is:

Optimize for change first.

What other people say

Other people have said this before and likely did a better job.

AHA Programming by Kent C. Dodds
The Wrong Abstraction by Sandi Metz
Please do repeat yourself (DRY is dead) by Rafal Stozek
Do Repeat Yourself by Ted Spence
Do Repeat yourself by Lucian Radu Teodorescu

Using Quartz as a Personal Blog

Mon, 08 Jan 2024 15:02:53 GMT

[!tldr] If you don't want all the backstory and just want to skip to the technical bits on how to use quarts for blogging and note taking with obsidian as your editor, click here.

Prologue - Dealing with perfectionism

I've been wanting to write blog posts, for a while now. Posts about things I'm learning, things I'm building and most importantly mistakes I've made.

The roadblock that's always been in my way has been my stubbornness.

[!quote] "I'm a web developer, I should build my own blog from scratch!"

Having a highly customized site would be awesome, and there's tons of great ones out there. Here's just a few of my favorites:

All those blogs are awesome. Especially Amelia's blog, who with just a glance will give all us mere mortals imposter syndrome no matter how long we've been in the industry.

The problem with all these developers sites, is they didn't start blogging with a cool site. They started with some kind of blogging platform like: dev.to, hashnode.com, or the OG Medium. Heck some developers happily use the default blog starter template of xyz framework.

What better person to use as an example than Dan Abramov with his site overreacted.io. In case you've been living under a rock, Dan created React.js.. er I mean.. Redux and Create-React-App. Oh and he works on the react core team at facebook.

Another example, we've got Ryan Carnianto who still just blogs to Devto. Who is Ryan? Creator of Solidjs, the framework that got everyone talking about Signals. If like me, you watch a lot of "Dev Youtube", SolidJS is the framework beloved by Both @ThePrimeagen and @t3dotgg.

Alright, we don't need to make our own. So what am I using?

Hold up, there's still some more backstory. Another "problem". Well, its not a problem per say, I just made it a problem, because I love getting in my own way.

I want to be able to edit my blog post drafts from all my devices, including my phone. During 2021, I fell in Love with a little quarantine project by the name of Obsidian. I loved the editor experience and wanted to use that for everything.

One thing to note with obsidian, while obsidian supports traditional markdown likes e.g. [text](relative-url), those can get cumbersome and obsidian defaults to using "wiki-links" e.g. [[shortest-url]] or [[shortest-url|text]]. And I much prefer wiki-links. So whatever I use needed to support wiki-links.

So, I tried making site after site:

And every time I had something, I just wasn't satisfied and I told myself "I couldn't blog until it was Perfect".

Enter Quartz

I was looking for a tool to make some documentation/wiki for a project and I stumbled upon Quartz. Quartz is a static site generator FOSS alternative to Obsidian Publish.

I tried it out for that project of mine and I loved it and instantly knew I needed to use it for my blog. The default site is gorgeously styled and would allow me to use Obsidian for editing and git for publishing.

Setting up Quartz

All I did was follow the documentation to create the starter project, change a few strings (like site name) and following their docs, I adjusted the layout a bit. I didn't spend much time on this step, most of my time was importing all my old blog posts.

While importing them, I didn't like how long my urls were, so I updated all my blog posts to have short urls. Maintaining canonical URLs is good for SEO, but none of my previews sites didn't have sitemaps and lets be real, most of my old blog posts aren't interesting or useful. I've archived a few really bad ones but I'll keep some for posterity.

By default Quartz comes with Plugin.RemoveDrafts() which is essentially an "opt-out" of being published. My plan was to unify my personal notes and blog into one Obsidian Vault, so this would be very tedious. Fortunately, Quartz has a second plugin Plugin.ExplicitPublish() which is perfect for my needs.

One additional benefit to the ExplicitPublish is I can publish individual notes that aren't in my blog folder. This way, say I've written up a personal note on how to use Postgres in docker, I can just publish that single note. (If this file links to other non-published files, Quartz won't publish those)

Aside from this plugin swap, the only other two major changes to Quartz's quartz.config.ts & quartz.layout.ts files was disable the Graph component and add a component to create a list of recent posts on the sidebar on desktop and above the footer on mobile.

tsx

Component.RecentNotes({
  title: "Recent Blog Posts",
  limit: 3,
  filter: (f) => (
    f.slug!.startsWith("blog/")
    && f.slug! !== "posts/index"
    && !f.frontmatter?.noindex
  ),
  linkToMore: "blog/" as SimpleSlug,
}),

Aside from that, at the moment, I'm pretty much using stock Quartz. Is my blog perfect? No. I'm itching to restyle it to match my colors in https://zanca-dev-v4.vercel.app.

My landing page

None of my previous sites had a landing page. I always wanted to make something cool like what my good friend Federico Terzi made on his site. (federico is the author of a super cool text-expander app called Espanso, you should go check it out!)

But honestly, I'm not very creative. Give me a Figma and I'll make it pixel perfect, responsive and give it that "feel good"/"power user touch" that apps like linear have.

Instead, while going to my Github profile looking for one of my old site repositories as inspiration, I had a realization.

I already have the perfect landing page.

And now, with my site done, I can start writing! (aka this article) Just note, when I say "Done", I mean done. Not perfect. I set a goal this morning, and I got that goal Done.

Actually I set up a few using pomofocus.io:

Quartz on mobile

Originally, I thought we could use git sparse-checkout set content to reduce the amount of files that needed to be checked for updates to improve obsidian-git's performance on mobile. But unfortunately, Isomorphic-git which is what powers obsidian-git, doesn't support sparse mode. If you try it, obsidian will throw an error telling you to create an issue on the isomorphic-git repository.

[!abstract]- If you're interested, here's what I wrote thinking this would work. Oops Since, we won't be editing code on mobile and all we care about is the markdown files inside the /content directory, we don't need to clone anything else.

What we'll do next is clone the repository with some flags on our PC then move the cloned repository on to our Android device.

TL;DR; here's the code
bash
git clone --filter=blob:none --no-checkout https://github.com/user/repository.git;
cd repository
git sparse-checkout set content;
git checkout;
The magic happens in two parts:

First we clone with the two flags: --filter=blob:none --no-checkout which will give us an empty working tree and will set the repository to lazily load the history of all the files from the remote.

Second we we use the sparse-checkout command to set it up such that when we checkout only the contents of the content directory will be pulled.

Lets see how that looks...

As you can see, when we clone the repository, its initially empty with just the hidden .git/ directory. Then after setting the sparse-checkout directory and checking out we end up with just the content folder. There's one last step that I can't show I'm afraid, and thats because we need to create a personal_access_token on github and use that in our clone URL.

Following their documentation https://publish.obsidian.md/git-doc/Getting+Started#Mobile

I was able to clone the repo on my PC, then move the file to my android device. Once there, it all opens fine and does work, though with pretty bad performance on the git status checks. This is because of all the files in the quartz directory slowing things down.

One idea is to use a submodule for the content, but getting the build on vercel to trigger when a submodule updates is going to be difficult. I can apparently get it to work with 2 github actions but its kind of spaghetti infrastructure at that point: https://www.perplexity.ai/search/github-action-detect-QLw0F4PRR1iaPObfmpKG4A?s=c

Ideally, this would be solved in Quartz itself, by moving all /quartz files to a npm package akin to how a framework like Solidstart has a package @solidjs/start that contains the framework and in the repository we've got just a few files that hook into the APIs exposed by the package.

I might reach out to quartz and ask if that idea is in the cards or if they wanted help with figuring it out.

I'm calling that a day. Overall, I'm very satisfied with the outcome and I'm excited to start writing more posts. Although, probably not using obsidian-git on mobile yet.

Github Actions for automatic Github Releases

Wed, 21 Apr 2021 00:21:18 GMT

I've really fallen in love with github actions. They make allow you to play around with continuos integration and enable so much automation for your personal projects.

If you've ever wanted to make automatic releases on github, look no further.

Step 1: Create the workflow file

Create a new file at this path

bash

.github/workflows/release.yml

If you're using vscode you can simply click new file and paste that path in. If you're going bare with a terminal have this:

bash

mkdir -p .github/workflows && touch .github/workflows/release.yml

Step 2: The Workflow itself

But first TL;DR: We're using Zip Release

And heres the code:

yaml

name: Release
on:
  push:
    tags:
      - '*'
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@master
      - name: Create Archive Release
        uses: thedoctor0/zip-release@master
        with:
          filename: 'release.zip'
          exclusions: '*.git*'
      - name: Upload Release
        uses: ncipollo/release-action@v1
        with:
          artifacts: 'release.zip'
          token: ${{ secrets.GITHUB_TOKEN }}

The long version. This action will only trigger when we push tags to the repository. Once triggered, it will first checkout the master(or main) branch using the "native" action for checkout. Afterwards it will zip using thedoctor0's Zip Release to zip up the contents of the repository and use the Release Action to create a new release using the newly created zip file as artifact.

You could conceivably create multiple zips or other types of packages (e.g. jars) to use as artefacts.

An example of artefacts is the releases of my personal minecraft [texture pack](https://github.com/metruzanca/minecraft-xpd-texture-pack

) where the pack is distributed as a .zip file.

In case you're also wondering what secrets.GITHUB_TOKEN is, I've asked myself that too. Basically its a token github can use within the action to authenticate as "the repository" in order to perform actions within the repository e.g. creating new releases. You can read more over at the Docs.

Step 3: Creating new releases

With the workflow created, unlike in my other guide for a gh-pages deploy pipeline which was triggered by pushing to master, meanwhile this workflow is triggered by pushing tags.

Whats a tag? Its basically a bookmark to a certain commit. Allowing you to easily say checkout tags/v1 or tags/v1.1

TL;DR

bash

git tag -a v<semver> -m "<release message>" # Creates a tag
git push --tags # This triggers the release

Now, theres a good chance that you'd never touched tags. So heres a quick guide:

To view your tags (q to exit as per usual)

bash

git tag

Creating Annotated tags:

Tags come in two flavours, normal tags and annotated tags. Annotated tags are best practice as they contain a lot of information (such as tag author), however you can use normal tags as temporary tags.

bash

git tag -a v<semver> -m "<release message>"

This is akin to making a commit, it stays local until explicitly pushing to remote. To do that we simply need to push the tags. git push will push everything but if you only want to publish tags theres a flag for that.

bash

git push --tags

The --tags flag is also available on fetch

bash

git fetch --tags

Step 4: Profit

If everything is setup properly, pushing tags should trigger a github action and create your release package.

Installing Linux on a Powerbook G4

Fri, 02 Apr 2021 22:37:39 GMT

My dad has an old MacBook from 2001, a PowerBook G4 that's been just sitting collecting dust for years. He wanted to try and revive it to use it for casual web browsing. So I told him he could probably pull it off by putting Linux on it.

After some research, I found the best distribution for this would Lubuntu as it has the following benefits:

Initial setup

First Download Lubuntu for PowerPC at https://lubuntu.net/downloads/. The direct download link seems to be down so a torrent client is going to be needed. I recommend webtorrent as it's very user-friendly.

Next you'll need something to flash a USB, balena etcher is cross-platform and will suit our needs.

With balena installed you can select your drive, the ISO you downloaded via torrent and get flashing.

Getting into PowerPC BIOS/boot menu

To get into the powerbook's bios you'll need to hold down this long combination after you turn on your mac Cmd⌘ + Option/alt + O + F.

After that you should be presented with a CLI with a white background.

Selecting the boot medium

PowerBooks are old, thus they don't have a GUI based bios and instead use a CLI. Normally I love me a good CLI as they are much more powerful if you know what you're doing. Sadly this bios is not very user friendly with obscure commands and no user manual. After some digging I found the correct command to boot from USB.

NB: if you have a non-american keyboard, while in this CLI your keyboard layout

will default to the american layout so this might come in handy.

if your keyboard has a fat enter key, the | and \ key will instead be to the left of the enter key instead of above.

For left usb port

bash

boot usb0/disk@1:,\\yaboot

For right usb port

bash

boot usb1/disk@1:,\\yaboot

Just to ring home how obscure these commands are, yaboot is an argument thats needed if the OS is linux based. Meanwhile tbxi is for OSX based. Why? Beats me.

Setting up Lubuntu

After these steps, you should boot into the trial of Lubuntu. From here you can experiment with the distro or install it via the desktop icon.

Following the install wizard should be easy enough.

And we're done! Enjoy your revived system.

Though if your G4 was like ours, 512mb of ram is going to be hard to work with, so be careful and setup a swap file or be prepared to reboot regularly when your system gets stuck when you run out of ram...

Gatsby.js blog

Sun, 20 Dec 2020 20:36:56 GMT

One of my greatest weaknesses is perfectionism. This is most prevalent in my personal projects where I have no outside stimulus, such as a deadline, to keep me focussed on creating the most value for the least effort. In my personal projects I have a tendency to want to overthink (because it's fun!) the problem and try to come up with creative solutions.

Whiling making something, I often end up researching some topic that came up and soon I find myself deep on a random topic (like this week was cryptocurrency). While this does add to my personal knowledge base and in some cases experience (as I may start another experimental project to apply what I learned), I often find that I deviated far from the original goal I had set.

This blog and portfolio, will hopefully be a step in the right direction to stop that bad habit of mine. Instead I will try to actually finish my personal projects and take note of topics that I would like to research further and schedule a specific time to explore and research those ideas.

This specific blog post was written during the processes of creating this site, so this will serve as a step by step guide for anyone reading and more importantly my future self.

Setting up Gatsby

After initially downloading the full example (thats using Netlify CMS and Gatsby) in order to get a feel for how they worked together, I decided to start from scratch following the Netlify Docs.

Following the guide on gatsby, I created a new gatsby site.

bash

gatsby new blog https://github.com/gatsbyjs/gatsby-starter-blog

After this, I knew I wanted my site to be built in Typescript and styled with Styled-Components. To configure these two, I made use of Gatsby's Recipe feature. Running gatsby recipes we get a list of all available recipes. From that list I found the ones I was interested in (and looked up a few others for future use)

bash

gatsby recipe typescript --install

To keep things neat, just in case, I actually decided to run the commands separately and make a commit for each of them.

bash

gatsby recipe styled-components --install

Setting up Netlify CMS

Add the netlify cms dependencies

bash

npm install --save netlify-cms-app gatsby-plugin-netlify-cms

Add the config file (which is setup to work with how gatsby's template is by default)

bash

├── static
│   ├── admin
│   │   ├── config.yml

yaml

backend:
  name: git-gateway
  branch: master

media_folder: static/img
public_folder: /img

collections:
  - name: "blog"
    label: "Blog"
    folder: "content/blog"
    create: true
    slug: "index"
    media_folder: ""
    public_folder: ""
    path: "{{title}}/index"
    editor:
      preview: false
    fields:
      - { label: "Title", name: "title", widget: "string" }
      - { label: "Publish Date", name: "date", widget: "datetime" }
      - { label: "Description", name: "description", widget: "string" }
      - { label: "Body", name: "body", widget: "markdown" }

This configuration allows placing the post assets along side the markdown files. Which I actually prefer to how Netlify's example project was setup.

bash

content/
├── blog
│   ├── first-post-title
│   │   ├── index.md
│   │   └── post-image.jpg
└── └── second-post-title
        ├── index.md
        └── post-image.jpg

The last step for Netlify CMS is to add the plugin to the gatsby-config.js file.

plugins: [`gatsby-plugin-netlify-cms`]

With all that done, in theory Netlify CMS should be correctly configured and all that remains is to push to github and add the project to Netlify.

Once added Identity Service and Git Gateway needs to be enabled.

The real coding begins!

Now that I've got everything working by following the guide from netlify's docs, I can get started on making my own changes.

Getting /blog/ in my posts path

First and foremost, I need to get a /blog/ path before all my blog posts. If I don't it'll be messy when I add pages later and will absolutely screw up SEO ranking if I change tha page's URL. So the earliest I get this done the better.

To get this done I'm going to edit the gatsby-node.js file and within the createPages function where it makes a call to the createPage callback I need to edit the path.

diff

  createPage({
+   path: `/blog${post.fields.slug}`,
    component: blogPost,
    context: {
      id: post.id,
      previousPostId,
      nextPostId,
    },
  })

For code blocks that have both language and diffing highlighting (like github does), you can do that with prism.js. (Gatsby comes with it out of the box) Instead of setting the language to e.g. js, you can use diff-js

Adding comments

Next up is adding support for comments. Theres this really nice project called utteranc.es which allows you to use GitHub issue comments for blog post comments. For anything but a developer blog, this would be inconvenient. However since this is indeed a developer blog, I feel like this is a great addition to the setup.

Not only does it make it easy to handle comments but it also makes contributing to articles that much easier. Say my dream to be come a well known developer like Dan Abramov comes true and I want to allow people to contribute to my blog posts by adding translations, I think utterances will help with the whole process. Keeping the conversation around a blog post all in one place.

Deploy website to GitHub Pages

Mon, 17 Aug 2020 23:35:00 GMT

I often create React or Gatsby apps and usually just opt to use github pages as a host.

Up until now my process for getting the build/ directory to where it needs to be, has been... messy to say the least. Today I've gone ahead and automated that once and for all and I've found what I think is a nice and easy solution. One thats also easy to setup for new repository.

Here's how it works.

Step 1: Create the workflow

Go ahead and create a new file at .github/workflows/deploy.yml with the following contents:

yaml

name: Deployment
on:
  push:
    branches:
      - master
jobs:
  deploy:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [12.x]
    steps:
      - uses: actions/checkout@v1
      - name: Use node ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      - name: Install dependencies
        run: npm ci
      - name: Build site
        run: npm run build
      - name: Deploy to gh-pages
        uses: peaceiris/actions-gh-pages@v3
        with:
          deploy_key: ${{ secrets.ACTIONS_DEPLOY_KEY }}
          publish_dir: ./build

The gist of this workflow is two fold:

The first part works out of the box (assuming you've used either create-react-app or gatsby-cli to bootstrap a project and thus have a npm build script), to get the second part working we need to setup a token for deploying. We've got a couple of options however I think the best and most convenient one is using ssh deploy keys.

Step 2: Create a new ssh key pair

Very important that you create a new ssh key pair and don't use one you might already be using if say you're using ssh with github. The reason behind this is that we're creating a key pair that our workflow will use.

bash

ssh-keygen -t rsa -b 4096 -C "$(git config user.email)" -f gh-pages -N ""

Step 3: Add the ssh keys to the repository

After generating the keys go over to your repository settings and add the following.

And We're Done!

The next time you push to master, this workflow will be triggered and will install, build and then create a new branch for us.

The last optional step would be to play around with the settings for gh-pages e.g. Adding a custom domain / subdomain.

Blog — Sam Zanca

Stop choosing Convenience

How I setup my SolidStart apps

Starting with the drizzle template

Change the Drizzle driver to libsql

Add tailwind

Notes

Tail-Call Optimization (in gleam)

Why does this matter?

Feels Like Mutation (But Isn't)

Example

TODO add more examples

Compiler Support for TCO

How I use Fish Shell

Autocomplete

General practices

My configuration

conf.d directory

functions

Command line tools I use with Fish

How to close the current window with JavaScript

7.2.2.1 Opening and closing windows

Repeat yourself, dammit!

Dry is Dead and we Killed it.

What other people say

Using Quartz as a Personal Blog

Prologue - Dealing with perfectionism

Enter Quartz

Setting up Quartz

My landing page

Quartz on mobile

Github Actions for automatic Github Releases

Step 1: Create the workflow file

Step 2: The Workflow itself

Step 3: Creating new releases

Step 4: Profit

Installing Linux on a Powerbook G4

Initial setup

Getting into PowerPC BIOS/boot menu

Selecting the boot medium

Setting up Lubuntu

Gatsby.js blog

Setting up Gatsby

Setting up Netlify CMS

The real coding begins!

Getting /blog/ in my posts path

Adding comments

Deploy website to GitHub Pages

Step 1: Create the workflow

Step 2: Create a new ssh key pair

Step 3: Add the ssh keys to the repository

And We're Done!

Change the Drizzle driver to `libsql`