I'm using SQLite in my latest project for the first time, and I wanted to give some praise to the VSCode extension SQLite3 Editor.
I love GUI interfaces for SQL (like my beloved phpMyAdmin), so I went looking for one for SQLite. Having the database just right there in VSCode when coding has been really nice. I'm just doing simple things like making sure my CRUD operations worked as expected, running a few queries, or double checking my database schema. This extension has performed rock solid for that use case, and it's super fast scrolling instantly with 30k rows.
The project author declared the extension feature complete last year, which I think is a pretty badass declaration to make.
I just went through the process of upgrading one of my web servers to Ubuntu 24 with the do-release-upgrade Ubuntu installer script, which I've never used before. Every time in the past I went to upgrade one of my servers, I deleted it and recreated from scratch. (yes, I take a backup too)
I wasn't super confident in what would happen but I wanted to give it a shot anyway, now that Walden's World and this blog are completely Dockerized I don't have nearly as much random commands I have to run to set up that server anymore, so my current installation is essentially default with Docker installed and config.
Preparation
do-release-upgrade required the server to be fully up to date on packages for Ubuntu 22, so I ran a few commands for updating:
There were a few things to confirm but the thing that scared me the most was this prompt about cutting off SSH.
Continue running under SSH?
This session appears to be running under ssh. It is not recommended
to perform a upgrade over ssh currently because in case of failure it
is harder to recover.
If you continue, an additional ssh daemon will be started at port
'1022'.
Do you want to continue?
I'm not entirely clear why port 1022 is fine when port 22 isn't, but I decided to ignore this and continue because all my servers are hosted with Linode. Linode has a feature called Lish Console that allows you to remotely "physically" access your server, so after thinking about it for a moment, if I did have a problem I'd be able to recover the server without using SSH on a direct connection. Plus I have a backup anyway. If you have a sudden power outage or internet loss it's good to have a recovery plan.
The installer also prompted me about needing a few gigabytes of space, but just to be safe I stopped and cleared out double what was recommended to make sure I wouldn't have any troubles with that.
Installation Process
Once I kicked off the installation it mostly went about on its own going through upgrading all the packages one by one. I was prompted a few times on the way to confirm some upgrades and about the config changes I had made to sshd_config and journald.conf. There was a merge conflict of sorts between the default config in Ubuntu 22 and 24, which makes sense because I had made my own changes to the config. I decided to go with Ubuntu 24's new config and then manually adjust my config back after the fact according to my own new server setup documentation.
The whole process took around 20-30 minutes for me, but perhaps if I had been watching closer I could've caught the prompts I got faster.
Finally, I was prompted to restart, and it worked!
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 24.04.3 LTS
Release: 24.04/bak
Codename: noble
That is, until I went to sudo apt-get update again. This is the only error I've run into so far after I upgraded the server.
N: Missing Signed-By in the sources.list(5) entry for 'http://mirrors.linode.com/ubuntu'
Since Linode is doing some special magic to mirror the Ubuntu package sources, I guess this wasn't accounted for in the official upgrade script. I followed this advice from a Stack Exchange post and was quickly able to get Linode's sources key readded:
I was having issues with my Docker compose project not picking up environment variables, with the following error:
b0sh@MacBook-Air-4 % sudo docker compose up
WARN[0000] The "LOG_DIRECTORY" variable is not set. Defaulting to a blank string.
invalid spec: :/log: empty section between colons
The project's docker-compose.yml file looked something like the following, where an environment variable was controlling the location of a volume.
Even though (I thought) I had that variable in my environment variables it wasn't picking up for some reason.
I then found out about the docker compose config command which was new to me and was very helpful for debugging. It prints your Docker compose file after all flags and variables are processed, as well as expanding out short form notations so that you can debug the config as Docker is seeing it.
After manually setting the variable with export LOG_DIRECTORY=/app/mysql/log I was able to see all my project's environment variables expanded out and noticed it was indeed working.
That's when I was able to realize that the issue was the LOG_DIRECTORY environment variable was in the project's variables.env file, not in a .env file. Docker wasn't looking at the non standard env file name. The actual project has a very complicated environment variable management system which I simplified here, so I got all bent out of shape and overlooked this simple fact.
I created a new .env file with the LOG_DIRECTORY variable and everything magically started working.
The docker compose config command was critical to unwinding this mess and I'm really happy to have this added to my toolkit working with Docker.
Additionally, when I had tried to run an export LOG_DIRECTORY=/app/mysql/log to test, at first I was running the config command without sudo, but running sudo docker compose up was triggering the environment variable not found error. Of course, that won't set the bash variable for the root user, triggering the error. I didn't notice this for a while, so if you run your Docker with sudo, also run the config command with sudo as well to get more accurate results.
Fascinating segment on The Vergecast this week on vibe coding.
One of the promises of AI is this idea that software will become commoditized and anyone can just whip up their own personalized app on a dime. Based on my experiences of getting genuinely useful apps with only a little bit of prompting, I've been agreeing with this statement as well. On the Vergecast, they set out to test that theory by vibe coding as people without any programming experience. ChatGPT made something, but nobody thought it went particularly well for them.
The fact that they couldn't get the apps to work according to plan isn't the suprising or interesting part to me. I've always had to spend a bit of time iterating on the prompt and doing back and forth to get a useful output. What was interesting was how they kept saying that ChatGPT was talking to them as if they were already programmers. For example, going through next steps or explaining the code. This was overwhelming for them and seemed to me to get in the way of their usage of the LLM.
I hadn't really ever thought about this because I already know the programmer speak, and so for me having ChatGPT use that language is actually helpful. But without that base of knowledge everyone ended up confused at what was going on. And furthermore, knowing that their apps weren't working as expected, they didn't have the language to communicate back in what ways to iterate on the code to move forward.
Considering the training data certainly scraped all the open source readme files and programming tutorials in the world, it makes sense that all of the specialized words and language around programming is baked into the models when it comes to discussing about programming. It seems plausible that you could improve the helpfulness of such vibe coded software with training data aimed at non programmers, but I think that even if you can make an app without knowing coding there's just no replacement for good solid programming fundamentals.
I've been using NVM Windows for a long time to easily switch Node versions for working with different apps. With NVM Windows it requires admin access to adjust the Windows environment for Node. However, my new corporate laptop policies got stricter with admin rights, and so I'm not able to just quickly elevate to admin to switch my node version anymore.
The solution I ended up using involved NVM sh and the Git Bash shell. I was able to install Git for Windows without admin, so that's what I went with. WSL also should work if you have that installed.