devin's blog

i like Fish

Tue, 24 Jun 2025 00:00:00 GMT

fish (friendly interactive shell) is a "smart and user-friendly command line shell for Linux, macOS, and the rest of the family". It contains so many useful features built-in, which you usually have to configure to add to other shells, and is overall much easier to work with than others.

I discovered it from a couple of my friends and it has made using the command line a lot easier and more attractive for me. It's pretty easy to install and use.

features

autosuggestions

Start typing any command and fish will try its best to complete the command for you. It also gets auto suggestions from your history. For example, lets say you had a long command that you ran a month ago and you wanna run it again:

❯ git log --au
    fish autocompletes for you based on history
❯ git log --author "intergrav" --since "1 year"
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                         (suggested completion)

Then, you can just press right arrow to accept the suggested completion, saving much more time than rewriting the entire command.

syntax highlighting

Fish will automatically highlight valid commands in one color and invalid ones in another. You'll know if you made a typo in a command before you press enter.

(good) tab completion

Fish can complete a ton of things. Some examples include file paths, commands and flags, git branches, environment variables, scripts from your package.json, and more. The completions for commands and flags are generated automatically based on man pages.

An example showing the tab completion for git commit -:

❯ git commit - # press tab here
-a  --all                     (Automatically stage modified and deleted files)
-C  --reuse-message   (Reuse log message and authorship of an existing commit)
-c  --reedit-message  (Like --reuse-message, but allow editing commit message)
-e  --edit                 (Further edit the message taken from -m, -C, or -F)
-h  --help                                   (Display manual of a Git command)
-m  --message                    (Use the given message as the commit message)
-p  --patch                        (Use interactive patch selection interface)
…and 14 more rows

An example showing the tab completion for $ (environment variable):

❯ echo $ # press tab here
$COLORTERM                                               (Variable: truecolor)
$COLUMNS                                                        (Variable: 78)
$EDITOR                                                       (Variable: nano)
$EUID                                                          (Variable: 501)
…and 114 more rows

better scripting syntax

The scripting syntax in fish is a lot more understandable and easier to read than the syntax in bash. Here's an example, taken from their website:

function detect_os
    switch (uname)
        case Linux
            echo "You're on Linux!"
        case Darwin
            echo "You're on macOS!"
        case '*'
            echo "Unknown OS: "(uname)
    end
end

compared to bash:

detect_os() {
    case "$(uname)" in
        "Linux")
            echo "You're on Linux!"
            ;;
        "Darwin")
            echo "You're on macOS!"
            ;;
        *)
            echo "Unknown OS: $(uname)"
            ;;
    esac
}

configuration through web browser

Run fish_config and it opens a web interface where you can customize colors and prompt. You can still configure it without a web browser if you want though.

installation

You can easily install fish on Linux, MacOS and BSD. See their home page for installation info. The documentation also has much more information about what it can do, how to use it, and how to set it as your default shell.

starship

After installing fish, you can use starship with it, which is a prompt thats very fast, customizable, and intelligent. It shows various things to you such as git status (current branch, changes, ahead/behind), language/package versions, ssh status, and a bunch of other information, all in a concise way.

Starship is not a shell, it's a prompt for any shell. I got confused about that when I heard of these two being used together, as I thought they were both shells. You can also use it with bash, zsh, powershell, etc.

For example, here I'm connected to my server (coolbox) with ssh, currently in a git repository (nixflake) on the main branch, and starship lists all of that information:

devin in 🌐 coolbox in nixflake on 🪾 main
❯ echo "hi"

To use it with fish after installing starship, just add this to your ~/.config/fish/config.fish so it runs:

starship init fish | source

Hopefully this helps!! :) This is my first blog post so if there's anything I need to correct then please lmk

goodbye GitHub, hello Tangled (pt 1)

Thu, 29 Jan 2026 00:00:00 GMT

For a very long time now, I've been contemplating switching away from GitHub and finding a better alternative. I have felt this for various reasons, which I feel I shouldn't need to explain, but here's a little summary of issues that I've seen from my own experiences and a couple of my friends:

UI has been getting very buggy and slow over the years. I've noticed significant slowdowns especially when browsing GitHub on my phone, which I do often
Occasional service reliability issues, atleast in my area. There's been cases recently where I haven't been able to download releases for some reason or even visit the site
Their intrusive push for AI, including Copilot, and losing focus on what really matters - the developer experience (see Leah's take on this, I share a lot of the same sentiment)
Owned by Microsoft, and haven't introduced any innovative features since the acquisition (2018!)
Many, many, many other complaints

Anyways. The only realistic options I've had other than GitHub for a while were either using GitLab, Codeberg or self-hosting my own Git forge. And here's a few reasons why I haven't switched to any of those.

I heavily dislike GitLab. It has so many performance issues and such a steep learning curve with it's very complex, cluttered and unintuitive UI. I just really never enjoyed using it, and that could also deter contributors.

Codeberg is not bad by any means, and I love what they do and stand for! However, nearly every time I've tried to switch to it I've had issues with it taking forever to load or not loading at all. Maybe I'm just very unlucky, idk. This seemed to have been a reoccurring issue for me and if I'm using a software forge I need it to be reliable.

And lastly, self-hosting a Git forge, from my perspective, can be a pain to deal with and is just not worth it for me. Because most of the time, from my knowledge, you have to run a mail server, set up your own account system, and setup oauth. I find it overkill, and it also deters collaborators as they have to make new accounts specifically to PR to my projects. And yes, while I am technically "self-hosting" Tangled, I'll get to why that's different.

..so, what is Tangled? and why?

Tangled is a decentralized Git hosting and collaboration platform, and these are reasons why I've been using it:

using Tangled gives you the best of both worlds: the backend (Git storage and CI) that contains the data you actually care about is decentralized and can be self-hosted, as in you can own all of your data. however, Tangled has a centralized frontend (App View) which acts as a consolidated view into the entire network, including those self-hosted instances. It keeps everything connected, and also simplifies self-hosting.
- For future reference, Tangled calls their Git storage servers "Knots" and their CI servers "Spindles".
- As an example, if I wanted to access my friend's repository on Tangled, I just go to https://tangled.org/friend2.org/coolproject, even if they are hosting the data themselves. I don't have to fiddle with accounts or anything, I can stay on Tangled.
- This means that people self-hosting a Tangled Knot don't have to go through the complexities of setting up account management, or a mail server, or anything like that. It only took me about 15 minutes to set up my own personal server.
- And of course, if you don't want to deal with self-hosting, you can just use Tangled's own storage and CI server aswell, which they provide for free. I just prefer to be able to easily back up and manage all my important data at any time, in case something like the GitLab incident happened again.

Tangled is built on ATProto, so you can optionally use a Bluesky account for login. Many people have Bluesky accounts nowadays, so you can just log in with that and you're good to go. No need to deal with manage a separate account, which is what tends to turn most people away.
- If you weren't aware, you can actually self-host your Bluesky account and it's data (they call it a Personal Data Server). The Personal Data Server contains your user and post data on Bluesky, along with user data for other ATProtocol services like Tangled.
- Bluesky operates their own PDS under bsky.social, which is the most popular PDS and is what most people use. Tangled also operates a PDS under tangled.sh. And, you can host your own aswell. You can even painlessly migrate all of your data between PDS's, without losing any followers or data as each person has a unique ID that doesn't change.
  - I recommend checking out the @me website if you want a visual representation of how the PDS works. Try entering in your Bluesky handle after logging in to Tangled with your Bluesky PDS!
Tangled's UI/UX design is amazingly simple, easy to understand, and very lightweight. So much so, that I even spent a day or two redesigning my entire website around this style. That's how much I enjoy it (okay well my website also just looked like total dogshit before, as I was lazy, but whatever...)
Tangled's pull request model is far superior to GitHub's. It follows a round-based pull request flow, with inter-diffing between rounds. You can just paste a git diff/git format-patch if you want to make quick changes! Of course, you can also just compare a fork as usual.
If you self-host your CI server, you can run workflows on your own infrastructure. And, it natively supports Nix, so you have access to pretty much any package you need. Seriously, Nixpkgs has everything.

There's a lot to love about Tangled as a code hosting service. They learned from the mistakes of previous software forges and made something very nice to use and polished. However, it is important to keep in mind that Tangled is very new. It's still in alpha, and is rapidly developing. At this time, it is currently missing a few features you may need which other forges offer:

Private repositories are not a feature yet
You can't run workflows on a cron job yet (to my knowledge)
There is no built-in static site hosting
- However, there are projects such as wisp.place which offer free static site hosting, integrated with ATProtocol. I'm currently using that to host this site right now, and you can find my automatic deploy workflow on my devins.page/devins.page repository on Tangled.
Still a somewhat small userbase at the moment. It may be cumbersome to explain what Tangled is, which is exactly why I wrote this!

As much as I would like to, I won't be fully switching away from GitHub. I'll still be using GitHub for my organization, along with my most popular projects such as devins-badges. I also still need to use it to contribute to most projects. However, I will be migrating my personal projects over. Maybe once Tangled is more mature I'll consider moving the other stuff.

But overall I've been very happy with the service these past couple days and I'm extremely ecstatic for what's to come. At some point I intend on making a "part 2" to this article explaining my experience migrating to Tangled, and possibly making a little guide to hosting your own Knot/Spindle (however I only really have ever done it on NixOS so it might just be better for you to follow the official documentation).

Please keep in mind: I am very new to this as I have only looked into ATProtocol and discovered Tangled pretty recently, so I could be wrong about some of the things I said regarding AT/Tangled in this article. Let me know if I should maybe edit anything. This is also one of my first proper articles I've ever written. I'll be writing more.

site changes and other updates

Sat, 20 Sep 2025 00:00:00 GMT

~~Using system colors again, since I didn't like the color scheme I came up with.~~ I made a new beige color scheme that I quite like, so this will probably stick for a while
~~Removed giscus comments since they were never really used and just adds bloat to the page. Maybe in the future I'll make a simpler comments system.~~ I've added it back, and mentioned it in the privacy page
Redesigned the header to be a lot more simple, moved external links to the footer.
Use serif fonts for headings, handwritten font for site title, just because I think it looks more pleasing.
Removed clientrouter which gets rid of site transitions, I felt like it didn't really fit well with this site and some browsers couldn't handle it properly.
Added back link underlines for accessibility

Besides that, I'm planning on maybe working on a few new projects in the coming months.

litedocs

Edit 5/18/26: This has been scrapped for a long time, I forgot I was even working on this

I was working on a documentation theme for Astro, similar to Starlight. The main difference is that it will be far, far more lightweight and minimal (like this current site). I haven't come up with a final name yet but I'll probably just call it "litedocs" or something. Once that's done, I may redesign the SkywardMC site to use that, so I can test it and make sure it works properly. It'll include the necessary stuff such as site-wide search with the pagefind api, a customizable sidebar for nav and external links, and internationalization.

While working on this, I had to make a lot of changes to slight.css to make it work better. So, that may get a new major version aswell. It mainly includes some cleanup and new variables to work with.

If/when this project is released, I'll make a post about it here. Maybe I'll also work on similar projects, like a blog theme. Slight.css, this project, and other stuff like that will probably be in under it's own organization.

tricks to make web apps feel native

Mon, 18 May 2026 00:00:00 GMT

For a few months I've been working on a music player for OpenSubsonic servers (Navidrome, Gonic, etc) called tinysub. Rather than a Qt or SwiftUI app, I went with a web app so that this could run on any device easily.

One of the biggest things I focused on while developing this app was performance, which Svelte and Vite mostly solved for me. But another thing I focused on was making it look and feel like a native application, atleast on MacOS.[^1] So I wanted to write down some notes about my experience, in case it might help someone in the future.

Here's examples of how it turned out:

I'm using Tauri to build tinysub, however I'm sure you could probably achieve all the same things with Electron.

tricks

1. use system font size and family

On MacOS (seemingly Windows too), most native applications typically use 13px (0.8125rem) font size by default for most elements. Browsers typically use 16px (1rem) font size by default. Changing the default font size can make a huge difference in how your application looks and feels compared to native, and having a smaller font size also lets you fit much more on the screen!

html {
	font-size: 0.8125rem;
}

Unless you are choosing a specific font for your brand, I recommend using the system font (San Francisco on MacOS, Segoe UI on Windows). Not only does this make your app bundle lighter, since you're not bundling any fonts, it also looks more consistent with the rest of the operating system. This is what I typically use, leaving sans-serif as a fallback for compatibility:

html {
	font-family: ui-sans-serif, system-ui, sans-serif;
}

2. some CSS properties to change

In the HTML element, you should probably disable user-select (and -webkit-user-select for Safari) so that your user can't select text, which stays consistent with native apps. You may want to re-enable this for body copy.

html {
	-webkit-user-select: none;
	user-select: none;
}

I recommend disabling overscroll so that you don't get that "elastic scroll" effect on the main window, which is seen when scrolling on trackpads or mobile devices:

html {
	overscroll-behavior: none;
}

I recommend hiding the tap highlight on iOS devices, which usually causes a blue tint when you press a button:

html {
	-webkit-tap-highlight-color: transparent;
}

3. use proper viewport sizing

Mobile browsers dynamically shift and resize their search and action elements to make more space for the page. The typical vh and vw units do not dynamically change with those elements, often causing the viewport to exceed the browser view area. To mitigate this, use dvh and dvw, which do dynamically change. (for more details, check out this article by Anthony Frehner)

body {
	height: 100dvh;
	width: 100dvw;
}

4. adjust whitespace for safe-area

Another thing you should consider is adjusting whitespace for safe-area. For example, on an edge-to-edge phone where rounded corners are part of the screen, buttons in a footer/action bar could be impossible to reach if they are located behind those rounded corners, or otherwise uncomfortable to reach if they are too close to the bottom edge of the display.

Luckily, this is very easy to solve, thanks to the CSS env(safe-area-inset-*) variables which dynamically change based on the device you're viewing on. In this case I went with borders instead of padding so that I could customize the color of the whitespace for each side, such as matching the bottom whitespace with the footer color of my app:

body {
	border-top: env(safe-area-inset-top) solid transparent;
	border-right: env(safe-area-inset-right) solid transparent;
	border-left: env(safe-area-inset-left) solid var(--bg-sidebar);
	border-bottom: env(safe-area-inset-bottom) solid var(--bg-footer);
}

On desktop these will typically have no effect but you will notice it on mobile devices:

5. use native context menus

In Tauri/Electron apps, I recommend using native context menus, which tend to be more accessible, more consistent, and gives you less code to deal with than making your own custom context menu. In tinysub specifically, I use a custom context menu in the web builds, and native context menus in the Tauri builds.

Here's the Tauri and Electron documentation to get started, and here's what it can look like:

6. consider a custom titlebar

You may want to consider a custom titlebar. Doing so can allow the titlebar to flow better with your content, or allow you to save space by placing actions in the titlebar itself. Personally, I did not make a custom titlebar for tinysub as I felt it wasn't necessary, and custom titlebars can often be a bit annoying on Linux.

Here's the Tauri and Electron documentation to get started on custom titlebars.

7. only show window after page is loaded

I recommend disabling window visibility on startup, and then have your app code show the window only once the page is ready. This prevents any flashing or blank screens while your app is loading.

Here's some snippets from my app:

let window = WebviewWindowBuilder::new((app, "main".to_string(), WebviewUrl::External(url)))
	.title("tinysub")
	.visible(false) // hide window initially, javascript code will unhide later
	//...other window properties

export const init = async () => {
	//...code to execute before showing the window
	if (isTauri) {
		const { getCurrentWindow } = await import("@tauri-apps/api/window");
		const win = getCurrentWindow();
		await win.show();
		await win.setFocus();
	}
	//...code to execute after window is done showing
};

8. window blur/vibrancy

On MacOS and Windows, it's relatively easy to achieve blur behind sidebars in Tauri with the window-vibrancy plugin. Vibrancy is possible on Linux desktops too, though on Linux, the compositor is what applies the effect, not the application itself, and only certain compositors support blur (i.e. kwin).

Here's a snippet from my app, though I'd recommend reading the full documentation:

use window_vibrancy::*;

// macos vibrancy (using sidebar material)
#[cfg(target_os = "macos")]
apply_vibrancy(&window, NSVisualEffectMaterial::Sidebar, None, None)
	.expect("unsupported platform! 'apply_vibrancy' is only supported on macOS");

// windows vibrancy (using mica material)
#[cfg(target_os = "windows")]
apply_mica(&window, None)
	.expect("unsupported platform! 'apply_mica' is only supported on Windows 11");

You will need to enable transparency in the Tauri window builder. After that, make sure to set the body's background-color to transparent so that you can actually see through the app, and then apply opaque colors to the main app section (in this case the song queue), leaving the sidebar transparent.

let window = WebviewWindowBuilder::new((app, "main".to_string(), WebviewUrl::External(url)))
	.title("tinysub")
	.transparent(true) // needed to see window-vibrancy effect
	//...other window properties

body {
	background: transparent;
}

#queue {
	background: Canvas;
}

This effect can really help make your app feel more consistent with the rest of the system, though I'd recommend making transparency configurable for Linux users who don't have a compositor that supports blur. And then that gives you this beautiful transparency effect:

9. styling tips

In tinysub I often used some OS-specific styling, such as a different color for the sidebar/titlebar borders to match native MacOS apps. I also used custom colors for item selection on MacOS. Tiny tweaks like these can make a big difference in how your app feels, even if the user doesn't notice it.

In a lot of cases I actually just avoided hard-coded colors entirely unless where necessary. Instead I opted to utilize the CSS <system-color> type for various colors, and the color-scheme property for light/dark mode. It can be a lot simpler to write this way and also look more consistent with other applications, unless you have specific colors in mind for your brand.

10: other tricks

For even more tricks on making your app feel native, this article by Vadim Demedes is a great resource. I just wrote this article to add on some other ideas too.

ending notes

Apologies if this article is a little sloppy, these were just notes that I personally wrote for myself while developing tinysub. Hopefully it was useful to you or informational in any way. If you have any suggestions, let me know in the comments and I'll edit the article accordingly.

[^1]: When I am referring to "a native look on MacOS", I am specifically referring to pre-Tahoe design. I don't intend on implementing Liquid Glass elements into my app as it's tricky to do in CSS, would be far too heavy, and I am personally not a fan of it regardless. However, the Cupertino theme for Obsidian does an excellent job on emulating the MacOS Tahoe design if you'd like to see an example of that.

the blog is up

Mon, 23 Jun 2025 00:00:00 GMT

I know this website may look very dull - I like it, and I believe that it works fine. I'll probably be implementing a theme switcher at some point for anyone that likes catppuccin or other themes.