DEV Community: Vincenzo

Omarcacca

Vincenzo — Wed, 21 Jan 2026 15:51:20 +0000

"Empty barrels always make the most sound" says my co-national Alborosie in Poser, and I thought this would not apply to DHH, the creator of Ruby on Rails, because he is not only noisy about his opinions, he is friggin loud as f***.

I had heard of him a few times before, and only in the last few years really followed him in some interviews/posts where he was just going always in
in an obstinate and contrary direction (to quote another italian singer/songwriter).

They left the cloud in 2023.
They stopped using typescript. ... and much more, that blog is a goldmine of opinionated opinions.

I have been using linux since 2006.
Ubuntu, Debian, Slackware, Arch then Ubuntu again, and I have been a big fan of minimal UI/WM/DE since forever.

In 2008 I started using a netbook, an ASUS Eee PC and since RAM was scarse I had to find a better way to provide myself access to tools, so I discovered and fell in love with fluxbox.

Loved it, even wrote a guide on how to configure it (is here in Italian).

When I got less time on my hand I moved to XFCE and then just plain GNOME.

Then few years back, in 2015, I got shown i3wm and used it on my ubuntu-netinstall until 2020, then I switched to Budgie and my personal laptop has been using that ever since.

So yeah I am no DE/WM/Tiling/Linux virgin.

When last year, around August 2025, I saw that DHH was coming out with a "distro" based on Arch I assumed it would be nice to check it out, so I did.

Omarchy looked amazing, it had some rough edges but had everything I needed, and it was flying.

The most amazing thing I found was the tiling system which I missed so much and did not even realised.

Few weeks in the first few cracks started to show, as I posted on bluesky here, I had an amazingly looking desktop, but way too many tools that I did not need/want.
Namely: 1Password, Neovim, kdenlive, office, obstudio, obs-studio, whatsapp, Bitwarden, ProtoVPN and a bunch of webapps (HEY, Basecamp, X) that I do not want nor use.

I found that tool to remove it, but then every few updates I got given something new I did not need. Something else broke, and even though I love to touch configurations I prefer to do it on my own ones, rather than the opinionated one of someone else.

I had issues where new tools like clipboard manager started to kill some of my personal tools, ntrallazzu, then keybinds changed on update and conflicted with some of my custom ones.

Then videos were not playing on brave/chrome and would only do that if I run it with a custom command, but that broke all of the other webapps.

I setup my editor to be zed instead of neovim but it was still no applying properly for config updates, since it was always using neovim.

Lastly, two of the applications I use every now and then do not work properly with it at all, Godot4 and ArduinoIDE are just completely broken and had to jump through so many hoops to just make it work.

The straw that broke the camels back was forced install of OpenCode, and then a bunch of more AI things which I never asked for.

I had enough, I hate microsoft approach of pushing Copilot into things, I am a big ChatGPT user, but I do not want all of that rubbish pre-installed, I just realised that I was in only for the hype and the rice.

F*** that.

I wiped and installed xubuntu minimal, I setup the tiling keybinds, installed a few of the packages I needed, it took me 2 hours in total, instead of the days I spent to setup and chisel away crap I did not need out of Omarchy.

If you know what you are doing it wont take much to setup and get your own DE/WM the way you want it, without the opinionated crap someone elses likes to dump on their crappy system.

Peace.

My XFCE keybinds
My Panel/Apps Setup

Oh forgot, doing webapps is simple as fuck, just bind the keys to brave (or chrome) --app=URL --new-window done.

My 2025 Tech Resolutions and My Plan for 2026

Vincenzo — Thu, 15 Jan 2026 09:20:20 +0000

Sup people, last year I posted this about my 2025 tech year resolutions, so a tech version of things I want to do/learn/try on the next year, and now that I've got a few minutes to reflect I will be doing it in here.

2024

In 2024 I said I would:

Learn Rust (for real this time), I abandoned it twice before. ✅❌
finish at least one of those sideprojects, or if not finish at least release it in a usable state.
✅
I had finished (and use them daily) 3 of them:
- Ntrallazzu: a cli tool to manage your sideproject folders, this one I even rewrote it twice, and converted to Typescript.
- Kiffari/kato: a notion clone meets obsidian but selfhosted and can do jira-like project management. This one is my first seriously big project written with Svelte and Go.
- tinchi: a kind of little css generator for utilities, a mix of tailwind and shadcn.
finish that football manager game you have been working on for the last 10 years with all of the programming languages.

❌
finish the Godot4 course and try release a game after that.

❌ I had started really well, but sort of lost interest.
start to learn something new not tech related necessarily. ✅

I started learning Japanese. Mostly using Duolingo at first, then I bought and read quite a lot of Genki and Japanese from Zero.

Also made Nise no Tori(Fake Bird) (source), a little rip off of a few little games to learn Hiragana/Katakana.

2025

One of the things I realised in 2025 is that I promised too much for 2024, so I went down another route, promise less.

How did it go?

Become proficient in Rust.

Finish again The Book. ✅
Finish again the rustlings. ✅
Make a Game in Rust with this, as suggested to me by the creator of that guide here ❌

Did not even touch this :(
Rewrite Muscurdi - Password Manager in Rust with iced, dioxus and/or tauri ❌

Did not any of those, but I have explored tauri and I am some ideas on some other sideprojects with it.
I did a little todo-app in tauri and svelte with a little persistence layer and it is lovely.
Release a little cli tool (maybe a hygen templates parser) in Rust. ❌✅

Released, and I only started on it recently: ruetta

Game Programming

Finish that Godot4 course. ❌

Did not, too verbose and boring.
Finish that little 2d shooter in Godot. ❌

Nope
Finish fdSimWeb and see whether is a good idea. ❌

Nope
Finish Sokkera (a little turn based soccer/football game). ❌

Nopety Nope
Rewrite Ammishka, a little WS turn based game framework, in typescript (maybe using deno instead of bun). ✅

I did alicarti, in bun and svelte.

Side Projects

Write a little Mobile Client for Kato/Kiffari (either react native or kotlin). ✅

I did better, I wrote a whole new system that uses ideas from Kato but works alongside the codebase you are using storing info in markdown files: kiffarino
Little Web interface to publish/read comic books on a static hosting provider. ❌

Nope

Learning

Finish at lease one of those courses on Blender you own. ❌

Did not even install Blender
Study Statistics, and Applied Statistics. ❌✅

I did start Brilliant but as all of the learning apps they are just engagement thiefs rather than actual learning tools.
Continue Studying Japanese with the aim to be able to watch some anime without subtitles. ✅

I did, I have my 650+ days streak on Japanese, but Duolingo is not enough.
Learn a bit of Korean, at least the alphabet and the writing system. ❌✅

Tried hindi, Arabic and Korean. already forgot everything :D
Learn and use Neovim. ❌

I tried, but then I switched to zed.
Finish a drawing class/course and start to publish some comic books/comic strips somewhere. ❌

I did not manage to do much more on this.

Results

So in 2024 I did 2.5/5 things I promised myself I would.

In 2025 I was a bit more granular and did 5.5/18.

So from 50% of something really hard I went to 30% of something really granular and spread around load of domains.

If feels not too much, but I have to say that I have done much more than that, only it was not on my radar when I started:

Learn Zig.

Did a course, and exercism, never got productive in it.
Uninstalled Instagram and replaced it with some more learning apps.
Finished a couple of courses on Mimo, Python, Typescript and SQL.
revamped and migrated some of my utility tools to bun:
- tinchi - my personal css framework
- ntrallazzu - a source code management tool
spiked back my interest in hardware programming, I used back some of the Arduino tools I had brought in 2012.
switched away from VsCode to zed, I wrote about it in here.

2026 - Here I come with more promises that will be broken

I will now formulate them as if I was speaking to myself, maybe doing so it will be more impactful?

For god sake finish a game dev project and publish it on itch.io.
Keep rust fresh on your mind and maybe migrate more of your tools to rust.
Try for real this time to dedicate some time to try out Drawing.
Make and publish somewhere a post about an hardware prototyping project.
Maybe stop wasting time on Duolingo and try out a real Japanese course?
Try to develop a Zed extension.
Keep an open mind about agentic editors, but keep doing what you enjoy/makes you more productive, do not fall for the FOMO.
Consume less short-video-format content and read/write more blog posts and watch longer videos.
Try to refresh some Advanced Math/Statistics with pen and paper exercises.
Keep spitting out sideprojects, getting those live makes you happy.

and that is all, see you in 2027.

Switching to Zed: Made my own VSCode-Rest utility

Vincenzo — Tue, 25 Nov 2025 11:25:53 +0000

I expressed my opinion about vibecoding and LLM usage before, and since then the dev world has gone batshit crazy about it and now every editor, OS, webapp, forces you into having to interact with a stupid AI agent that most of the time is freaking useless.

AGAIN, I use LLMs (specifically ChatGPT) day in and out, to do boring stuff, like creating tests or solving specifically small problems I can't be bothered to copy paste. ChatGPT is my StackOverflow, I want it out of my editor and possibly on my browser.

Unfortunately vscode, one day, decided to break my VSCode Minimal Setup I had run for the last few years to add bloody CoPilot bars, tabs and crap all over the place.

I had enough, so decided to give a serious go to zed.

I had only used it to try out a faster and more modern vim, so I had activated the vim-mode and gone ahead and done some coding for a couple of days, then I just uninstalled it.

after the situation with VSCode ended up like:

I decided to give it another go, especially for an amazing feature, which is vscode is not so obvious.

or if you speak settings.json

  "agent": {
    "enabled": false
  },

Yeah I know, Agentic shit is enabled by default, but it has one switch.
I am ok with that approach, I mean, I use brave as a browser and I always have to turn off all that crypto rubbish they have leftovers from the good old days where the hypetrain was bloody NFT and CryptoCrap.

Anyhow, I spent more than 2 weeks using only zed instead of vscode and I found just a few little issues, but loads of improvements.

I just set it up to use vscode keybinds and customised the one I had customised in vscode.

The UI is fast and responsive, it loads superfast both on Linux and Mac, it supports most languages natively, without any extensions, I know right?

Svelte

The only one I had to install was the Svelte language server with their extension.

Finding stuff in .env

By default if you file is in .gitignore the filescan wont show it nor you can search it, but you can fix it with this setting:

  "file_scan_inclusions": ["public/", "data/", ".env*"]

Anything missing?

I was shocked to see how productive I was with little to no extensions installed, until I hit 2 "hurdles".

Hurdle 1: Debug

Debug Tests

I have not had an absolute necessity to debug vitest, but that is something I use a lot, and I cannot find a way to make it work properly, but have not put myself into it too much.

Debug Bun

I use bun for all of my sideprojects, and debugging the main flow works (better than in vscode), but I cannot find for the life of me a way to debug bun:tests.

Hurdle 2: VSCode-rest

I use a nice vscode extension called vscode-rest and I love it.

I plop loads of those .http files in all of my sideprojects.

Those files are just a set of http calls, and their setup, they allow me to test some endpoint without switching out of the editor.

Pity that there was no extension that supports that syntax so I did what every dev on a sideproject does... starts another sideproject to help with the first sideproject.

POSO

I read some info on how to make a zed extension but it was too long and I decided I NEEDED it NOW.

So I went off and as I have done with a couple of my side projects:

tinchi - my own compact tailwind
ntrallazzu - my project launcher
kiffarino - my local md files based jira (wrote a post about it here)

I created a cli tool installable via npm.

I have build (or migrated to) all of those tools with bun, so I can use typescript without having to build, but then I compile them to a single javascript file that I push to npm.

I used this pattern so much that I created a little template too.

Anywho what did I want here?

I just wanted to re-use my http files really, nothing more complex than that.

those files are structured like so:

### getOne
get http://localhost:3003/api/tickets/01JZ5WE7A0RQTNFY0B188D8HVG

### link
POST  http://localhost:3003/api/tickets/01JZ8CRNQ7S69AHR9X541A97ZR/link
Content-Type: "application/json"

{
    "type": "linked",
    "linkedId": "01JZ8E15XQ8CZ71KXKJT6TXDG6"
}

### unlink
DELETE  http://localhost:3003/api/tickets/01JZ5WE7A1ZKRXG2WW1DWFPJPQ/link/01JZ5WE7A0RQTNFY0B188D8HVG

### udpate
PUT  http://localhost:3003/api/tickets/01JYRK01WZ69BYMSTDHMM5QR80
Content-Type: "application/json"

{
    "type": "bug",
    "status": "inProgress"
}

they have sections, you can specify named requests and add body and headers.

Another thing you can do is specify variables

@apiUrl = my.api.com/api
@someStuff = 185

GET {{apiUrl}}/things/{{someStuff}}

and, if you are a poweruser you can calculate those vars from other requests.

I decided that it was a bit too complicated to start with that depth of support so I focussed on the simpler cases of hardcoded vars, that you could overwrite via flags.

But yeah, few days in and I've got a poso that can be used.

And the code is here.

Now I can forget about vscode, until I find the next hurdle.

How I use LLMs: BadVibez Coding

Vincenzo — Sat, 12 Jul 2025 12:24:51 +0000

TLDR

LLMs save time and reduce friction, but they do not replace experience. Use them to speed up the parts you already understand, not to blindly build what you cannot explain. Otherwise you might get dumber and lose touch with how things work.

I’ve been coding for about 20 years, professionally since around 2009.

I’ve seen a lot of change in that time. Not as much as someone who lived through the dot-com bubble, but certainly more than people who’ve only ever worked with React.

I also have a Bachelor's Degree in Computer Engineering (Laurea Triennale in Ingegneria Informatica), so I’ve studied serious math and physics. But what has shaped me most is not just education, it’s the projects, the missteps, and the way the industry keeps evolving.

The Last Few Years Feel Different. But Are They?

The past two years, especially the last one, have felt like something big is shifting in our field. But at the same time, I realize this is not entirely new.

When I was 17 or 18, I was making websites on Ubuntu with HTML, CSS, and some jQuery to handle AJAX. I wrote a bit of PHP and used raw MySQL to generate HTML on the server.

At one point, someone asked me to build a YouTube clone. So I did.
Users could upload videos via FTP, log in, manage their content, and play videos using some odd Flash player.

When I delivered it, he told me he would only pay 10 percent of what we agreed on. His reason? He said it was already built, and he could just recreate it in Dreamweaver.

That was the first time I was told I might be replaced by drag-and-drop tools.

A few years later, I was told my custom PHP CMS was useless because Joomla could do everything. Then came WordPress. Then came Wix.

Now we are hearing the same thing again, but this time with AI.

What Hasn’t Changed

The tools change. The trends change. The way we approach problems keeps evolving.

What doesn’t change is this:

A curated, well-maintained codebase is always better than something generated by a machine, even when it’s partially reviewed or tweaked by humans.

No-code and AI can be helpful. Use what gets the job done. But don’t forget that thoughtful engineering still matters. It always has.

Vibecoding

When I first saw the term "vibe coding" a few months ago, I was really curious.

That video blew my mind, not because it introduced a revolutionary technique, but because I recognized the same pattern I had seen many times before.

As the trend grew, I saw more and more people suggest, or at least imply, that a tool could fully replace human thinking. I was not just skeptical, I was also a bit annoyed by the idea.

Later, during a hackathon at work, we were given access to Cursor and told to use it to build some prototypes.

It was great, only it wasn't.

The project was a cloud-based to-do manager that used another AI service to read your task list out loud each day. Some features worked. Others were clearly borrowed from existing tools or APIs and roughly adapted.

I added a simple integration with Todoist to handle create and delete operations. That part was fine, although the implementation was a bit messy.

But as soon as I tried to do something more complex, like keeping track of local updates that were not yet synced to the backend, most of the suggestions I got were hallucinated.

After tweaking and editing the code, I eventually got it to work, but the result was something I would never want to maintain. Especially the second part, where I tried to connect to the paid tier of ElevenLabs for text-to-speech. Even when I pointed Cursor to the official documentation, it still suggested completely made-up APIs.

In the end, prototyping with vibe coding can be useful. It can help you prove that an idea might work. But you are the one left cleaning up the mess.

You get to an MVP quickly, but the cleanup is much harder. When you finally want to move to production, you often do not even know where to begin and what to take apart first, as the code is not at all yours.

What do I do instead?

That does not mean that I do not use LLMs in my day to day, quite the opposite.

What works better for me is taking a bit more time during prototyping. I try to write most of the important parts myself, and I let LLMs help with unit tests or small pieces of logic, asking for partial solutions to small problems, once I already know what I want the overall architecture to look like.

gnoring the help LLMs can give you is stupid, but so is thinking they can completely replace the input of seasoned engineers. Engineers forged through thousands of hours spent digging through Stack Overflow and GitHub issues.

That is what LLMs do for me. They replaced my googling. They replaced the time spent writing things I already understand. Now it takes me minutes to solve small problems, not hours.

They help me set up unit and integration testing quickly. It takes me seconds, not hours.

I also use them to compare libraries or approaches for solving domain-specific problems.

But I do the coding. I do the copy pasting. And I know exactly what each line of code does (mostly).

Here are some example of prompts I have used whilst working on or ideating Kiffarino (this is a post on dev.to on what it is and what it does.)

Going back to my experience at uni, LLMs are like scientific calculators. You still need to understand the problem and know how to solve it. The calculator just helps you get there faster.

If you delegate a problem to a calculator without understanding what the solution is, you are not an engineer. You are a manager, a business analyst, a product owner, or one of those startup CEOs with two employees.

I like to keep using my brain. Delegating too much feels lazy. It makes me feel disconnected, unneeded, and a bit useless.

Maybe I am a control freak, but I like to understand how things work. That is the main reason I love programming. And if I ever get too comfortable handing off the parts I enjoy, I might as well stop programming altogether.

To me, it feels like buying a triple A game, ($70) and then watching someone else play it on Twitch.
Something about that just feels lazy and frankly pointless.

Kiffarino: you local trello/jira for your sideprojects.

Vincenzo — Sat, 05 Jul 2025 11:14:34 +0000

Whilst working on a side project, which idea came whilst working on a previous side project, I had an idea again, and this became the sideproject I will be telling you about today.

I did briefly speak about it in here but now I actually finished it as a little MVP.

Today I present you Kiffarino, a local first, file based Project Management Tool.

(Bun/Svelte5/Typescript/Hono)

Think about it like your local Trello.

Why did I do it?

Most of my sideprojects end up with a big readme.md file with a bunch of TODOs that I end up forgetting what they meant.

Few years back I created kiffari/kato, a self-hosted notion/trello alternative, but even though I use it quite a lot, I would like to have my tickets close to the code, so I can keep them close and never forget what they are for.

And that was the idea that made me switch side project.

What if I could run Kiffari, but locally, I could create a little cli utility that uses a set of folders and files to generate a kanban board where I could keep track of my tasks, tickets, docs and all.

And here it is a little demo of the MVP:

What does it do?

Quoting the readme:

Kiffarino is a lightweight, local-first project management tool built for developers and small teams who prefer a simple, CLI and Web based workflow tracking tool.

It lets you manage tasks, tickets, and projects directly within your project folder — no complex setups, cloud services, or external tools required.

Just fast, minimal, local productivity.

It's like Jira, but simple and it just works.

Features

🗃️ Local-first ticket and task management — Everything is stored locally in plain files, no cloud required.
⚡ Lightweight — Minimal dependencies, with a total size of ~420 KB.
🏷️ Flexible ticketing — Supports tags, filters, and status tracking out of the box.
🛠️ Modern stack — Built with TypeScript, Bun, and Svelte 5. 📝 Markdown-based tickets — Tickets are just Markdown files you can open and edit manually anytime.

You just install it via npm i -g kiffarino and the command kfr will be ready for you to use.

go to a folder where the sideproject is and.

kfr init # to init the config file (you can edit the folder and project name)

kfr generate # to generate the folder structure a a couple of example tickets

Then

kfr start

to serve the web ui.

And then you will have your locally running trello/jira without paying and only weighing ~400kb.

Where do we go from here?

I might start using it in the project I was working on, but I have a few more ideas to implement first, and all of them are in the README.md.

Should I use kfr to manage kiffarino as a project too? Probably.

But before using it I want to at least do the following:

Implement the Docs management (just a set of ui utils to manage markdown files stored in a docs/ folder)
Use the priority flag in the UI to order tickets.
Implementing Drag&Drop to move tickets across states in the board
Move away from zod (it is nice but it takes loads of those 400Kb even minified for just a few schema checks)
Add Epics/Milestones to categorise tickets under a certain target.
Tags Autocomplete/Search by Tags.
A way to restore archived tickets.
Github binary release so people who do not use npm nor node could download it as a standalone binary.

Let me know what you think, or open a PR!

👉 github.com/vikkio88/kiffarino

Monorepo with Bun

Vincenzo — Sun, 22 Jun 2025 09:26:29 +0000

Hello

Had this idea recently. I built this project management tool kinda like Jira, called kiffari, and now I’m working on turning it into something that runs locally, using markdown files as a database. It’s called kiffarino. The whole point is to keep tickets right next to the code that handles them

But this post isn’t really about that.

It’s about how much I’ve gotten used to bun as my go-to JavaScript runtime. I almost forgot it can also transpile TypeScript for Node, work as a package manager, and handle monorepos too. It does all of it.

Over the past few months I’ve moved most of my stuff to bun. It just makes sense. I love JavaScript. It’s the language I use the most and the one I feel fastest with. TypeScript grew on me too. Not because of the safety everyone talks about, but because the type hints are nice. It’s basically inline docs that actually work

What used to really piss me off with TypeScript was the setup. Every time I started a new side project it was the same annoying routine

Init the project with npm or pnpm
Copy a massive tsconfig from some other repo
Try to run it with ts-node or tsx or figure out how to build it properly

It’s not awful if you have a good starter or template, but still, too much time wasted before you even write a line of code.

If also you want to have monorepo, with shared libs, the headache gets increasingly bigger, as you need to multiply the effort of all of those boilerplate nonsense.

I have used pnpm and nx for work, it works really well but the boilerplate you need to just get going is just too much.

Bundle that, build this, transpile that other one and by the time you get going that initial idea is getting boring and your side project is dead.

I have used bun so far as a runtime, monorepo manager and a package manager, so I decided to give it a go as a transpiler too.

Long story short, it worked.

In kiffarino, I have the following setup:

a hono backend
a svelte5 spa
a shared lib to share types and functions between the 2 repos. (Endpoint results for example)

I had done that before in other repos (alicarti a game framework for websocket games), but using bun as a runtime, so it was all good easy and smooth.

Here I wanted to create a single executable, to be compatible with node and be able to publish it on npm as a package I can use everywhere.

And it all just works.

How did I do that?

Easy:

Backend

"build": "bun build ./src/index.ts --outdir ./dist/ --target node"

This just transpiles and makes it runnable by node with only one command.

Frontend

"build": "bunx --bun vite build"

vite handles it really well but run via bunx

Shared libs

{
  "name": "@kiffarino/shared",
  "module": "index.ts",
  "type": "module",
  "devDependencies": {
    "@types/bun": "latest"
  },
  "peerDependencies": {
    "typescript": "^5"
  }
}

Only adding that index.ts and it looking like this

export * from "./config";
export * from "./models";

it allows me to use those libs everywhere in the monorepo.

It just works wonders and to setup the workspaces, as suggested from their docs, you only need to do two things:

This in the root packages.json

  "workspaces": [
    "be",
    "web",
    "shared"
  ],

and as long as those packages have a name in them, this what you can put so the subrepo can see stuff exported by other ones.

  "dependencies": {
    "@kiffarino/shared": "workspace:*",

and to use them you can just

import { Ticket } from "@kiffarino/shared"; // <-- isnt this great?
import type { Context } from "hono";

[...]

export async function create(c: Context) {
  const body = (await c.req.json()) as { title: string };
  [...]
  const ticket = Ticket.create(body.title);
  return c.json(
    {
      result: ticket,
    },
    201
  );
}

Setup finished.

How to run scripts concurrently you ask?

"dev": "bun --filter '*' dev",
"check": "bun --filter '*' check",

this will look in * all of the workspaces and check if a dev script is in the package.json and run it.
The second one is to do a typecheck instead.

In the case of a hono repo is a bit more complex as bun does not do typechecking.

But adding this is enough:

"check": "bunx tsc --noEmit -p tsconfig.json",

In short, bun has completely changed how I handle JavaScript and TypeScript projects. It cuts through the usual setup headaches, speeds up development, and keeps everything simple—even in monorepos. If you’re tired of wrestling with configs and build pipelines, give bun a shot. It just works.

auto y2025 = new Year(); // Resolutions

Vincenzo — Thu, 02 Jan 2025 14:19:52 +0000

Sup people, before the end of the year I went through a mad web search through all of my social media to gather my 2024 resolutions, and I could not find where I had posted them.

I thought it was mastodon, no.
Maybe Bluesky? no.
Facebook? fuck no.
Linkedin? Nopety.
Twitter? No fucking way I post in that crap.

I think it must have been threads, but I have since deleted/nuked my profile since the app was only spamming me with random pointless notifications about posts I did not care about, so yeah I had lost them, so I gathered my memories and tried to think what they were and tried to assess whether I had indeed managed to achieve anything:

Rust

Learn Rust (for real this time), I abandoned it twice before.

✅❌ Yeah, not really. I did have a good run, but in the end I caved under an annoying little problem on one of my exercises.

SideProjects

finish at least one of those sideprojects, or if not finish at least release it in a usable state.

✅ OMG did't I do just that? YES!

I finished (and use them daily) 3 of them:

Ntrallazzu: a cli tool to manage your sideproject folders, this one I even rewrote it twice, and converted to Typescript.
Kiffari/kato: a notion clone meets obsidian but selfhosted and can do jira-like project management. This one is my first seriously big project written with Svelte and Go.
tinchi: a kind of little css generator for utilities, a mix of tailwind and shadcn.

Finish that Football manager game

finish that football manager game you have been working on for the last 10 years with all of the programming languages.

❌ Nah, I did not do it, in fact I rebooted it once again, after Avalonia/dotnet and Go/fyne (this last one being the further away I have even been), I just rebooted it once again as a browser game with bun/hono/solidjs just for fun fdsimweb.

Godot

finish the Godot4 course and try release a game after that.

❌ I had started really well, but sort of lost interest.

Learning/Expand Horizons

start to learn something new not tech related necessarily.

✅ I started learning Japanese. Mostly using Duolingo at first, then I bought and read quite a lot of Genki and Japanese from Zero.

then of course I had to do something programming-wise and made Nise no Tori(Fake Bird) (source), a little rip off of a few little games to learn Hiragana/Katakana.

I also got back into drawing (I was doing little comic books when I was 10-14), I am not ready to share
anything though :D.

Overall not too bad I would say.

OMG it's 2025 now

I think one of the best thing that made me go through with some of those resolutions last year was the sheer volume of them, it kept things fresh and made me bore less.

So I am going to create a new list for next year and save it in here so I can always come back and look to see how I am doing, also I will add little steps so I can kind of track progress and achievements for the main goal.

Become proficient in Rust.

Finish again The Book.
Finish again the rustlings.
Make a Game in Rust with this, as suggested to me by the creator of that guide here .
Rewrite Muscurdi - Password Manager in Rust with iced, dioxus and/or tauri
Release a little cli tool (maybe a hygen templates parser) in Rust.

Game Programming

Finish that Godot4 course.
Finish that little 2d shooter in Godot.
Finish fdSimWeb and see whether is a good idea.
Finish Sokkera (a little turn based soccer/football game).
Rewrite Ammishka, a little WS turn based game framework, in typescript (maybe using deno instead of bun).

Side Projects

Write a little Mobile Client for Kato/Kiffari (either react native or kotlin).
Little Web interface to publish/read comic books on a static hosting provider.

Learning

Finish at lease one of those courses on Blender you own.
Study Statistics, and Applied Statistics.
Continue Studying Japanese with the aim to be able to watch some anime without subtitles.
Learn a bit of Korean, at least the alphabet and the writing system.
Learn and use Neovim.
Finish a drawing class/course and start to publish some comic books/comic strips somewhere.

God that is loads, let's see what will happen.

I will keep it up to date as the year goes, so next year I do not need to go around the world looking for this post.

OMZ: Some Plugins that I forget about

Vincenzo — Tue, 19 Nov 2024 09:40:25 +0000

I have a terrible memory, that is why I posted this about how I setup my dev machine.

Recently also I have remember that not only I install ohmyzsh and set it up as I want, I usually setup some plugins (apart from the git one which comes in enabled as default).

Jira

If you have ever worked in IT you know that you have at least once used Jira, I hate it so much, that is why I started a sideproject to manage my sideprojects Kato/Kiffari (but that is something for another post).

Well one of the thing that jira has is ticket codes, say a project is called WEB PLATFORM, and your ticket is the 187th, your ticket code will be probably WEB-187 or something of the likes.

If you need to review some info on it, you usually have to go to the board, find your ticket, and click on it, but ohmyzsh has a nice little plugin that will open the ticket for you via shell:

jira WEB-187

this will open the jira ticket on your default browser as long as you setup a ~/.jira-url file looking like this:

~
❯ cat ~/.jira-url
https://YOURCOMPANY.atlassian.net/

How do you get it?
Well if you have ohmyzsh install you already have this plugin, you only need to enable it adding it to the plugin array in ~/.zshrc

❯ cat ~/.zshrc
export ZSH="$HOME/.oh-my-zsh"

ZSH_THEME="refined"
plugins=(git jira)
// more stuff here

NVM

Working with node and some old apps it always means that your default node version might be a bit too fresh for the project itself.

Hopefully you use nvm.

For example in my machine I have set by default the version 23.1.0, the stable one when I setup this machine.

~
❯ nvm list
       v18.20.4
       v20.18.0
->      v23.1.0
default -> stable (-> v23.1.0)

But on a project I am working on I have a .nvmrc file that tells me NOPE.

some-project git:chore/some-branch-name
❯ cat .nvmrc
v18.20.4%

The solution to make everything work fine is always to do a good old:

❯ nvm use
Found '~/code/some-project/.nvmrc' with version <v18.20.4>
Now using node v18.20.4 (npm v10.7.0)

But if you have multiple windows/tabs and you need to run scripts elsewhere, it quickly gets annoying to remember to do it.

Introducing the NVM PLUGIN:

to enable it as the previous one just add the nvm string to the plugin folder, plus a little setting I have found useful:

❯ cat ~/.zshrc
export ZSH="$HOME/.oh-my-zsh"

ZSH_THEME="refined"
plugins=(git jira nvm)

zstyle ':omz:plugins:nvm' autoload yes

This last line makes the plugin autoload the correct node version when you switch in a folder with a .nvmrc file and switch to the default version when you cd out of it.

~
❯ cd code/some-project
Found '~/code/some-project/.nvmrc' with version <v18.20.4>
Now using node v18.20.4 (npm v10.7.0)


some-project git:chore/some-branch-name
❯ cd
Reverting to nvm default version
Now using node v23.1.0 (npm v10.9.0)

~
❯

Easy peasy and one less thing to type in to get your code going.

More info on this plugin can be found here.

Personal TODO list on how I set up my dev machine

Vincenzo — Tue, 19 Nov 2024 09:18:22 +0000

I am a Linux fanboy, I have been using Linux (and especially Debian-based distros) since 2007 more or less. In 2007, I started using Ubuntu Gutsy Gibbon and when I wanted to upgrade to Ubuntu Intrepid Ibex I did it from the package manager, and disaster occurred.

My machine wouldn't boot up.

Since then every time there is a need of upgrading the system I have always installed it anew (keeping the /home partition from the old system) using the USB/cd live cd.

Fast-forward to a few days ago. I've been using Ubuntu 20.04 since 2020, and my package manager went "Yo biatch Ubuntu 22.04 is out, get on it" and even though I had that bad experience in 2008, I thought it was maybe time now to give it a try and upgrade distro while on a distro.

BAD CHOICE.

It all seemed like it was working but the day after, the PC was stuck on a boot loop, so I knew I had to reinstall stuff.

Luckily I am not that much of a paranoid freak, so I do not encrypt my hard disk, I managed to salvage the only 100kb of config files I needed by mounting the had on a live USB stick and put moving those files to a pen drive.

Yet I had to install stuff back to get them all as I wanted them to be, so I decided to write a small post on how I get my machine set up.

TODO

After a fresh install of Ubuntu I install the DE, I have been using Budgie and I love it.
Install Terminator as a terminal emulator, and I set up the keybinds to be the same as iTerm on mac so it is easier to remember when I use my work MacBook.
Install zsh, switch bash to zsh as my shell and install oh-my-zsh
I plop my .zshrc with few shortcut and theme I like in ~.
I am a javascript kind of guy, so I install nvm first.
I install hygen that I use to generate source code, and my templates.
I generate a new set of ssh keys, and add them to Github and on my raspberry pi (so I can ssh into it).
I generate the config for my raspberry pi to connect using identity_key.
I install: Discord, Brave, [Telegram(https://desktop.telegram.org/) and VSCode, which then I sync with my github profile to pull down my settings.
I install go.
I install: build-essential.
I install httpie.
I install docker (this is quite a boring process, to make it sudoers and so I can run without sudo). On Mac instead I use podman.
I install Spotify.
I set up my keybinds on Budgie: I use Super+Shift+Q to close windows, Super+Enter to Open a terminal, and a few other ones that I've been stuck with me since my early fluxbox days.
I troubleshoot why Alt+Ctrl+Arrows keybind doesn't work following a question I have also asked in the past.
Create a ~/code folder, to keep all my coding stuff in there.
Install the latest tools I have been using/learning: atm Godot, rust (via rustup).
I lose interest and never want to touch this PC ever again.

And that is it. I hope this list would be helpful to someone, it will definitely be helpful to me if in a few years I forgot again NOT to upgrade the distro.

I keep a little setup installer and info on this repo.

Go(lang) to F*** yourself

Vincenzo — Thu, 08 Feb 2024 10:20:05 +0000

DISCLAIMER

This is only my personal experience and might differ from yours, I do understand and just want to share this point of view.

Since the dawn of my time programming, I have never felt like being a fanboy for a certain technology or platform.

I have preferences, yes, but I have never been #teamJava #teamCPP or anything of the like.

I think programming languages are tools to solve problems and you use different tools to solve different problems.

One of the programming languages I have been using more and more in the last few years is go.

I love it. the syntax just works so well for me, the simplicity and power of this language are astonishing.

It is easy to pick up and work with, and since the code is quite simple you can go back after months and still your code is easy to read and the syntax is easy to pick back up.

The ONLY single flaw I found so far is one, The Community.

There are great people, but overall every time you ask for info and advice you only get 3 really:

You should rewrite that using only the standard library.
Read the docs.

And that is not how you deal with people asking questions, I am a polyglot and have been working with different other programming languages and I feel like Go is the best for potential and the worst for community gatekeeping.

People have been generally unhelpful and a bit patronising, with a slight hint of perceived disgust for someone trying to understand what is the correct way of doing things.

I think Go would be a great language for everyone to work with, it is far superior than it used to be and even though the tooling is not as good as the one you find in rust (cargo is the best tool of any programming languages), it has improved massively and now it is quite nice to work with.

There are loads of packages for anything you need, it is easy to install and use them but the docs are usually lacking in examples and too verbose to be helpful.

I feel like those who code in Golang would change their attitude towards newbies it will probably benefit the ecosystem with more people working with it and on it.

Nonetheless, I do feel like the benefits of working with Go outweigh those little problems, and even though is slightly harder to find help it is still worth it.

Now that I have expressed my feelings about it, I just wanted to know if am I alone in thinking this or did someone else experienced the same?

Creating a TODO app in Fyne an Go

Vincenzo — Sun, 21 May 2023 12:24:51 +0000

In this small tutorial I will explain something that usually is the exercise that allow you to understand how to use a UI framework (at least in the web world), and we will end up step by step in building a TODO app in Go using the Fyne UI Framework.

I will assume that you have at least some knowledge of programming, but it would also be great if you have some knowledge of go, personally I found it the easiest Programming language to learn, you can just find more on how to do that in their learning resources.

It would also be better if you follow the installing instruction of fyne in here.

What are we going to build

It is simple really, just a small app that will allow you to keep a list of things to do, that you can check off if you once done them.

It should look like this:

Setup Project structure

Go has had a bad past for how everything used to be stored in a GOPATH folder, libs, vendors, your own personal projects, but since v1.14, with the introduction of go modules everything makes more sense and is way easier to understand.

We want to init our project, so create a new folder then init the module

$ mkdir todoapp && cd todoapp
$ go mod init todoapp
$ touch main.go

Some people suggest you to call the module with the url of the github repo you will use to version control it, but it does not really matter if you are not planning to use it elsewhere but in this binary.

open this folder in your favourite code editor and drop this on your main.go

package main

import (
    "fyne.io/fyne/v2/app"
    "fyne.io/fyne/v2/widget"
)

func main() {
    a := app.New()
    w := a.NewWindow("TODO App")

    w.SetContent(widget.NewLabel("TODOs will go here"))
    w.ShowAndRun()
}

Now before running it let's reference fyne and tidy the go modules

$ go get fyne.io/fyne/v2@latest
$ go mod tidy

After that is done, let's try to run it

$ go run .

You should see somewhere in your Desktop a small application window that looks like this:

Nothing much to look at, but if you reached this point you are pretty much all set and from now on it will all be great.

You can now do 2 things.

Create the models for your app to show
Design the UI

I tend to create (usually with TDD) the models the app will show first, so I know what I need to bind in the view, especially in this case where we only have 1 model (Todo) I guess we will be all set quite soon with that.

Todo Model

I would make a folder called models and drop in 2 files

$ ls models   

todo.go
todo_test.go

I won't go too much into the testing otherwise we will just take forever, so I will just show what todo.go declares

package models

import "fmt"

type Todo struct {
    Description string
    Done        bool
}

func NewTodo(description string) Todo {
    return Todo{description, false}
}

by default the constructor will set the Done property as false.
I also added a func String() string function to implement the Stringer interface.
So I can stringify my todo if I wanted to

func (t Todo) String() string {
    return fmt.Sprintf("%s  - %t", t.Description, t.Done)
}

Now let's try to show one in our fyne app, but first maybe, let's make that window a bit bigger

func main() {
    a := app.New()
    w := a.NewWindow("TODO App")

        // ADDING THIS HERE
    w.Resize(fyne.NewSize(300, 400))

Now it should look more like this

great, now let's create a TODO and show it in the same window.

    w.Resize(fyne.NewSize(300, 400))

    t := models.NewTodo("Show this on the window")

    w.SetContent(widget.NewLabel(t.String()))

This is what we get

Brilliant.

Now it is time to create the actual Interface.

Ux Design

Fyne, like many other Desktop UI frameworks has layouts that can be contained to define how the widgets and items will be positioned around the available space in the window.

There are loads and they are all showcased in here and in the Containers/Layouts section.

Let's try one, let's push that todo in the center.

// make sure you import the right one
import "fyne.io/fyne/v2/container"
// this ↑

        w.SetContent(
        container.NewCenter(
            widget.NewLabel(t.String()),
        ),
    )
    w.ShowAndRun()

in the api examples you can see that this can also be achieved with this form

    w.SetContent(
        container.New(
            layout.NewCenterLayout(),
            widget.NewLabel(t.String()),
        ),
    )
    w.ShowAndRun()

Which I personally dislike, The first one is syntactic sugar for the second one.

Anyway the app will look like this now:

Nice! but we want one Text entry and a button on the side, to input and add the todo to a list don't we? Well let's combine stuff and use the Border layout.

    w.SetContent(
        container.NewBorder(
            nil, // TOP of the container

            // this will be a the BOTTOM of the container
            widget.NewButton("Add", func() { fmt.Println("Add was clicked!") }),

            nil, // Right
            nil, // Left

            // the rest will take all the rest of the space
            container.NewCenter(
                widget.NewLabel(t.String()),
            ),
        ),
    )
    w.ShowAndRun()

This will add a button at the bottom and on click it will print on the console standard output "Add w as clicked!"

This is what it looks like:

Now let's add the entry at the side of the button, in another container type, HBox, this will stack the item horizontally

    w.SetContent(
        container.NewBorder(
            nil, // TOP of the container

            container.NewHBox(
                widget.NewEntry(),
                widget.NewButton("Add", func() { fmt.Println("Add was clicked!") }),
            ),

            nil, // Right
            nil, // Left

            // the rest will take all the rest of the space
            container.NewCenter(
                widget.NewLabel(t.String()),
            ),
        ),
    )
    w.ShowAndRun()

But unfortunately it does not look right, we want them to take all of the space available.

We can try a few more:

            container.NewGridWithColumns(
                2,
                widget.NewEntry(),
                widget.NewButton("Add", func() { fmt.Println("Add was clicked!") }),
            ),

will look like this

            container.NewBorder(
                nil, // TOP
                nil, // BOTTOM
                nil, // Left
                // RIGHT ↓
                widget.NewButton("Add", func() { fmt.Println("Add was clicked!") }),
                // take the rest of the space
                widget.NewEntry(),
            ),

Nesting another border in the border bottom:

It does not really matter, it is a matter of personal preference but I will go with this last one.

Cleanup and Todo Creation

We now have designed our UI will look like, but let's try to clean up the code as the container tree is quite messy already.

I will move the button and text entry creation before the .SetContent call like so:

    newtodoDescTxt := widget.NewEntry()
    newtodoDescTxt.PlaceHolder = "New Todo Description..."
    addBtn := widget.NewButton("Add", func() { fmt.Println("Add was clicked!") })

    w.SetContent(
        container.NewBorder(
            nil, // TOP of the container

            container.NewBorder(
                nil, // TOP
                nil, // BOTTOM
                nil, // Left
                // RIGHT ↓
                addBtn,
                // take the rest of the space
                newtodoDescTxt,
            ),

declaring those widget before will allow us to modify properties and add handlers to them before getting them into the actual content tree.

In this example I added a placeholder to the entry text so it is clearer what it is for:

Now let's make the "Add" button do something, and even disable it if the text is empty or too short.

    newtodoDescTxt := widget.NewEntry()
    newtodoDescTxt.PlaceHolder = "New Todo Description..."
    addBtn := widget.NewButton("Add", func() { fmt.Println("Add was clicked!") })
    addBtn.Disable()

    newtodoDescTxt.OnChanged = func(s string) {
        addBtn.Disable()

        if len(s) >= 3 {
            addBtn.Enable()
        }
    }

this will disable the button if the text length is less than 3 character:

and enable it otherwise

Great! Now let's try to build the last piece of the UX we are missing, the List of todos.

Lists in Fyne

There are 2 types of List widget you can use for this purpose, the first one is a static type of list, the second is one which content is linked to the data it will show.

Simple List has a simple API.

            widget.NewList(
                // func that returns the number of items in the list
                func() int {
                    return len(data)
                },
                // func that returns the component structure of the List Item
                func() fyne.CanvasObject {
                    return widget.NewLabel("template")
                },
                // func that is called for each item in the list and allows
                // you to show the content on the previously defined ui structure
                func(i widget.ListItemID, o fyne.CanvasObject) {
                    o.(*widget.Label).SetText(data[i])
                }),

in our particular example we want each list item to have a label for the Todo description and a checkbox to show whether the todo is marked as done or not.

Just to try out what it looks like let's create this data as a slice of Todos.

    data := []models.Todo{
        models.NewTodo("Some stuff"),
        models.NewTodo("Some more stuff"),
        models.NewTodo("Some other things"),
    }

// then on the last func of list we just replace `data[i]` with

                func(i widget.ListItemID, o fyne.CanvasObject) {
                    o.(*widget.Label).SetText(data[i].Description)
                }),

and it will look like this:

as you can see there we are getting the o CanvasObject and type casting it to a *widget.Label that is because we know that the function before creates that particular widget, as I said before though we need a Label and a Checkbox, they need to go in a container also, so we can kind of do the same with did with the bottom bar and space them so the label takes most of the space.

                func() fyne.CanvasObject {
                    return container.NewBorder(
                        nil, nil, nil,
                        // left of the border
                        widget.NewCheck("", func(b bool) {}),
                        // takes the rest of the space
                        widget.NewLabel(""),
                    )
                },

Something like this.

But unfortunately this will throw a compile time as the o CanvasObject is not a *widget.Label anymore.

We need to cast it to a Container, then get the widgets nested within using indexes, and cast them all to what we know they are (as we defined them we should know).

                func(i widget.ListItemID, o fyne.CanvasObject) {
                    ctr, _ := o.(*fyne.Container)
                    // ideally we should check `ok` for each one of those casting
                    // but we know that they are those types for sure
                    l := ctr.Objects[0].(*widget.Label)
                    c := ctr.Objects[1].(*widget.Check)
                    l.SetText(data[i].Description)
                    c.SetChecked(data[i].Done)
                }),

and this is what it looks like now

Personally I find that casting thing quite weird in the API and getting the order of the components within a container is a bit hit and miss, might need to try compile a couple of time to see whether [1] is Label or Check for real.

Anyway we got there but if we add another todo to that data the list won't reflect the changes, as we are just using a static simple list, if we want to make it dynamic, and we need to for our app, we need to use binding.

Binding and Dynamic Lists

Binding is explained in the docs quite well for simple types, but not at all for Struct types, which is what annoyed me the first time I tried fyne.

What you do really is create a DataList, add the items from our slice of todos and use another widget api to render the list.

It will look quite similar to what we did here, but in our case, since the type of DataList we create will be of Untyped type, we will have to add one step more than a primitive type, to cast the data item to our own models.Todo struct.

here it is how you create the data list

    data := []models.Todo{
        models.NewTodo("Some stuff"),
        models.NewTodo("Some more stuff"),
        models.NewTodo("Some other things"),
    }
    todos := binding.NewUntypedList()
    for _, t := range data {
        todos.Append(t)
    }

it would be nice if you could set the items on creation maybe but the API does not allow to do that yet.

then this is how the list creation looks like now

            widget.NewListWithData(
                // the binding.List type
                todos,
                // func that returns the component structure of the List Item
                // exactly the same as the Simple List
                func() fyne.CanvasObject {
                    return container.NewBorder(
                        nil, nil, nil,
                        // left of the border
                        widget.NewCheck("", func(b bool) {}),
                        // takes the rest of the space
                        widget.NewLabel(""),
                    )
                },
                // func that is called for each item in the list and allows
                // but this time we get the actual DataItem we need to cast
                func(di binding.DataItem, o fyne.CanvasObject) {
                    ctr, _ := o.(*fyne.Container)
                    // ideally we should check `ok` for each one of those casting
                    // but we know that they are those types for sure
                    l := ctr.Objects[0].(*widget.Label)
                    c := ctr.Objects[1].(*widget.Check)
                    diu, _ := di.(binding.Untyped).Get()
                    todo := diu.(models.Todo)

                    l.SetText(todo.Description)
                    c.SetChecked(todo.Done)
                }),

this other casting bit is the one I found hard to get right too

                    diu, _ := di.(binding.Untyped).Get()
                    todo := diu.(models.Todo)

We get a DataItem which is a binding.Untyped underneath, we need to Get() it, the cast it to our model, then we can finally use it.

I usually move the functions within a list to separate functions and make a small method on the models package to handle that type of casting, so it looks a bit less cluttered.

something like this

// in models
func NewTodoFromDataItem(item binding.DataItem) Todo {
    v, _ := item.(binding.Untyped).Get()
    return v.(Todo)
}

// so in the list function will look like so
                func(di binding.DataItem, o fyne.CanvasObject) {
                    ctr, _ := o.(*fyne.Container)
                    // ideally we should check `ok` for each one of those casting
                    // but we know that they are those types for sure
                    l := ctr.Objects[0].(*widget.Label)
                    c := ctr.Objects[1].(*widget.Check)
                    /*
                        diu, _ := di.(binding.Untyped).Get()
                        todo := diu.(models.Todo)
                    */
                    todo := models.NewTodoFromDataItem(di)
                    l.SetText(todo.Description)
                    c.SetChecked(todo.Done)
                }),

Anyway, now let's do the last step, how to add a new todo?
Just use the data list on the addBtn func like so

addBtn := widget.NewButton("Add", func() {
        todos.Append(models.NewTodo(newtodoDescTxt.Text))
        newtodoDescTxt.Text = ""
    })

and once you click on it, it will magically add it to the list, and show a new list item on the List component.
As a small nice feature, we need also to clear the text entry so we are ready to add another one.

We could also use the Prepend method instead of Append so the Todo will take the first place in the list instead of the last.

Other notes

If you want to change the actual items it is better to create a slice of *models.Todo so they will use the real value of those rather than a clone.
There is no Remove api in the DataList for now, so to remove something you need to hack around with the slice within.

// to remove them all for example you should do something like this
        list, _ := todos.Get()
    list = list[:0]
    t.Set(list)

If you are interested in the code example I uploaded it on my github here: github.com/vikkio88/fyne-tutorials/tree/main/todoapp

If you want to see a more complex example with some syntax sugar and sexy db persistence layer using clover you can look at this gtodos.

I also added an example branch without the db just for "fun" here

And finally, if you are interested in a more complex app example I posted here about me rewriting a Password Manager in Fyne and managing in a couple of days to create and distribute the app using github actions.
Muscurd-ig.

That is all folks, please let me know what you think or if something is not clear.

See you next time.

Fyne, I'll do it myself: Adventures in Desktop App development

Vincenzo — Sat, 20 May 2023 12:26:07 +0000

Almost a year ago, I wrote about I was really trying hard to get into Desktop GUI apps development here, and someone suggested me to try Fyne.

Which I did, and wrote some first impressions about it in here.

I said there that the docs weren't really clear and some stuff felt a bit hacky to do, which it is totally still the case, but since then many things have changed.

I tested Avalonia and loved it.

I even wrote an article here on how I wrote in just under 2 months a multiplatform password manager application, which builds on github action and works on Mac/Win and Linux.
Muscurd-i is the app, and the codebase is quite huge to be such a simple application.

Few weeks ago instead I got my coding mojo back and hacked a bit around with rust, vlang and went back to study go once again (I wrote about it in here also).

This is the way I learn programming languages, I do side projects and since then I felt like I had to give fyne another go.

I finally completed the todo application which I was mentioning on the post before, and I was quite silly not to see why it didn't work before codebase is here.

Now it all works like a charm, and since I was on a roll I decided to give a try to move my password manager to Fyne and golang.

I did.

It took me only 2 days to reach feature parity and a couple of hours to setup a set of github action to build the binaries.

This is the repo.
This is what the latest release page looks like here.

The only thing I needed in here which was not supported out of the box with Fyne, was a routing system, which I was shocked to find so easy to create myself using their binding apis and a bit of creativity.

In this project basically the app creates a context to pass around the views, and maps the string representation of the route to a view which it is "mounted" in the main window content:

        views: map[c.AppRoute]func() *fyne.Container{
            c.Setup:     func() *fyne.Container { return ui.GetSetupView(&ctx) },
            c.Login:     func() *fyne.Container { return ui.GetLoginView(&ctx) },
            c.List:      func() *fyne.Container { return ui.GetPasswordListView(&ctx) },
            c.Details:   func() *fyne.Container { return ui.GetPasswordDetailsView(&ctx) },
            c.AddUpdate: func() *fyne.Container { return ui.GetPasswordAddUpdateView(&ctx) },
            c.About:     func() *fyne.Container { return ui.GetAboutView(&ctx) },
        },
    }

// Getting the view given a route
func (a *App) getView() *fyne.Container {
    key := a.ctx.CurrentRoute()

    if content, ok := a.views[key]; ok {
        return content()
    }

    return a.views[c.Login]()
}

// reacting to the view change
a.ctx.OnRouteChange(func() {
        val := a.ctx.CurrentRoute()
        a.log(fmt.Sprintf("route state changed %s", val))
        if val == c.Quit {
            a.application.Quit()
        }

        a.setView()
    })


// changing a route from any view then looks like this
    aboutPageBtn := widget.NewButtonWithIcon("", theme.InfoIcon(), func() {
        ctx.NavigateTo(c.About)
    })

I was really proud of that, I even did a small change so I could pass a parameter around, for routes with ids for example.

I know it feels a bit web applike but every other ui framework has routing systems, that is just the way the UX world goes I guess.

I also managed, as mentioned before, to setup a whole set of github actions to build the app binary for Win, Linux and Mac, and it took me literally 2 hours without almost no trial and error that usually you end up doing when you work with CI/CD tools.

The app looks like this on linux after you install it:

Everything just worked and I felt productive like I probably never have on Desktop GUI app development.

What is next? Maybe I will finally finish one of the projects I tried to do many times before, a Football Manager clone focused on the Players Transfer Market.

Let's see if this mojo streak lasts.

And what about you? Have you tried fyne? GO AND DO IT NOW!