If we’re making a list of great projects written in Go, I’m putting in a word for PocketBase which is a based around sqlite that works as a backend-as-a-service and does all the tedious auth work for you. It’s the perfect sideproject backend.
For anyone without the inclination to wade through 47 pages, here’s what they say about HTMX, which they’ve classified as “Assess” rather than “Trial” or “Adopt”
htmx is a small, neat HTML UI library that recently became popular seemingly out of nowhere. During our Radar discussion, we found its predecessor intercooler.js existed ten years ago. Unlike other increasingly complex pre-compiled JavaScript/TypeScript frameworks, htmx encourages the direct use of HTML attributes to access operations such as AJAX, CSS transitions, WebSockets and Server- Sent Events. There’s nothing technically sophisticated about htmx, but its popularity recalls the simplicity of hypertext in the early days of the web. The project’s website also features some insightful (and amusing) essays on hypermedia and web development, which suggests the team behind htmx have thought carefully about its purpose and philosophy.
Us looking at developers still on dBase III ~inserts Judgmental Volturi meme~
Great point. Sometimes the benefit of an external dependency being changeable is a great feature.
I read an interesting post by Ben Hoyt this morning called The small web is a beautiful thing - it touches a lot on this idea. (warning, long read).
I also always feel a bit uncomfortable having any dependencies at all (left-pad never forget), but runtime ones? I really like to avoid.
I have Clipper complied executables written for clients 25 years ago I can still run in a DOS VM in an emergency. They used a couple of libraries written in C for fast indexing etc, but all statically linked.
But the Visual Basic/Access apps from 20 years ago with their dependencies on a large number of DLLs? Creating the environment would be an overwhelming challenge.
You don’t need the GUI, the client does all the work. I use a Debian container, so just sudo apt-get install boinc-client.
Once that’s installed, you go to the project (in my case, World Grid) and setup your account. As part of that, it will give you a URL and account key. Then back on your server, you use the boinccmd to --project_attach the URL and key.
I boinc in an LXC container with a cron job to run during the period in the day on weekdays when the electricity is pretty much all renewables (and I’m not watching Jellyfin). The intention is to turn sunlight into tiny forward progress towards curing cancer.
Specifically, the Community Grid projects Mapping Cancer Markers and Smash Childhood Cancer.
I switched from Copilot to Codeium after only a couple of months of Copilot use - just based on the cost since currently I’m just a hobby coder.
The main difference I’ve noticed is that Codeium doesn’t seem as smart about the local context as Copilot. Copilot would look at how I’m handling promises in a project, and stick to that, whereas Codeium would choose a strategy seemingly at random.
A second, and maybe more telling example, is that I do my accounts using ‘plain text accounting’ in VS Code. This is a very niche approach to accounting software and I imagine is hardly in the training sets at all - there certainly would not be a lot of public domain text accounts in the particular format (BeanCount) I use in public code repositories. Codeium doesn’t make any suggestions for entries as I’m entering transactions, whereas Copilot would see that the account names I’m using are present in another file in the project and suggest them, and very quickly figure out the formatting of transactions and suggest them correctly.