I've had a good experience with Woodpecker CI. I've heard that installation and integration with ForgeJo isn't easy, but I deploy everything to my homelab using Dokku, where I push a Dockerfile, mount a volume (on setup), and it's good to go.
I assume this isn't optimal for a business setup, but for personal projects, I don't miss GitHub Actions at all.
.env files are a different use case than config files.
You can use them together. Config files provide configuration to the application. The config file can read environment variables, so you can deploy the same code across different environments, e.g., your local computer, staging, and production.
Then, each environment will provide system-related configuration, e.g., `DATABASE_URL`.
With this setup, the same code will work on each environment.
Now, .env files should live only on your local machine; on any other environment, they should be set differently, not in files.
The .env file is a convenience, but not the only option for environment variables, nowdays you can use 1Password too.
Why don’t we just switch over to Vue? If DX is such a driver for deciding to use a web framework, Vue kicks React’s ass, and that’s just objectively speaking.
Well not technically switch, I never learned React properly because I didn't like it when it first came out and by the time I gave it a second look there were already a gazillion React devs so I just stuck with Vue.
Vue just seems much more intuitive and sane to me. Sane is relative for front end frameworks of course. Don't get me started on Angular I got PTSD and couldn't code for a couple of months from a large Angular project with an offshore team.
I do get the benefit of using these framework for teams, and they are nifty once you get what is happening, but I still scratch my head when I see all the steps and files to do simple things I used to bang out in a few dozen lines of jQuery.
One of the greatest things of the Vue community is that they are not dogmatic about a technology choice. They welcome everyone, and proof of that is that they are building tooling that benefit everyone not only their community.
So, we can switch over to Vue whenever we want. I personally prefer React and I'm super grateful of Vite and their ecosystem.
I came to reply this. They have been building very cool CLI projects and those projects end up composing new bigger projects. This is their last one (That I know of) which use most of the other projects they created before.
They didn't do it flashy for this project specifically (like Claude Code, which I don't think is flashy at all) but every single one of their other projects are like this.
Additionally, the explanation might work for the exec asking the question, but not for others.
I don't like that executives don't have to put in the effort to communicate their concerns and put pressure on the people who already have the pressure of researching, validating, and presenting the solution.
I'm probably going deeper than I should. Still, if the executive asking the question isn't technical, he could direct the question to the executive who's supposed to have a technical background that earned their position in the company. You know, people making decisions should have an understanding of what they are building/selling.
One common leadership trend is to give minimal feedback like “this is not cool” and rely on competent people directly under the executive to guess what that means.
Competent people can often lead themselves in the right direction, especially with the use of copious after-meetings in which everyone tries to interpret the executive’s feedback.
After all, the executives are busy and hard to get access to.
I think using Aider[1] with Google's models is the closest.
It's my daily driver so far. I switch between the Claude and Gemini models depending on the type of work I'm doing. When I know exactly what I want, I use Claude. When I'm experimenting and discovering, I use Gemini.
I assume this isn't optimal for a business setup, but for personal projects, I don't miss GitHub Actions at all.
reply