I worked with Nathan a couple years ago (Hi Nathan!) -- if you can hire him, you absolutely should. He'd be an amazing addition to any team.
1,850 karma · joined February 21, 2014
Same story with Racknerd: https://www.racknerd.com/dedicated-servers (they have new years deals rn too!)
yadm made it difficult for me to take specific actions when a file changed. For example, I configure a lot of macOS settings in my dotfiles (https://github.com/cweagans/dotfiles/tree/main/dot_config/ma...). When any of the JSONC files change, I need to run a script to actually apply them (https://github.com/cweagans/dotfiles/blob/main/.chezmoiscrip...), but I don't want to do that unconditionally. Chezmoi tracks that state for me and only runs the script when needed. Ditto with the macOS config profile (https://github.com/cweagans/dotfiles/blob/main/dot_config/ma... and https://github.com/cweagans/dotfiles/blob/main/.chezmoiscrip... respectively).
I was also not thrilled about the idea of shipping an encrypted blob of important secrets around. I want my dotfiles to be public, so it's much nicer when the tool I use for managing my dotfiles natively integrates with 1password. Much of the templating functionality that I use from chezmoi is specifically for pulling stuff out of 1password.
Finally, the yadm "alternate files" functionality is nice, but I didn't really care about alternates for different OSes or hostnames or whatever. I wanted some configuration for my work machine(s) and some configuration for my personal machine(s) - that's it. That's the only distinction I care about. Chezmoi made it easy to prompt for the type of machine + change the things that get configured accordingly when bootstrapping a new machine (https://github.com/cweagans/dotfiles/blob/main/.chezmoi.toml...).
Consider that the statement "their intuition is always twisted and wrong" is itself probably wrong. Their intuition is based on their professional and personal experiences. Two different people with different experience are not going to have the same intuition and that's okay. It's not productive to turn that into a personal judgement ("this person arrived at a different conclusion than I did - let's figure out why" is very different from "this person is an unteachable idiot")
Personally, I'd consider this an opportunity to help develop somebody's talent. I happen to find mentoring to be a very fulfilling part of the job though, so I lean into it a bit more than is strictly necessary. I'd probably start approaching this as a teaching problem, rather than a collaboration problem. If _telling_ this person something doesn't work, _show_ them. If that doesn't work, get some hands-on time by pairing with them on some tasks (in whatever configuration works -- try letting them navigate or drive, and you fill the other role).
If all of those things fail, go to your manager with something along these lines:
"I've been working with so-and-so on some things that they got stuck on. It has impacted the time that I have available for the work that is assigned to me. I'm happy to continue doing that if you're okay with the time investment (roughly x hours over the past month)."
If it's really impacting your work, they'll probably ask why it's taking so much time, so follow up with something like:
"In pairing with them, I've identified some knowledge gaps around x, y, and z -- the time spent is not just on the task at hand, but also in mentoring/teaching to get them up to speed in those areas. If it's too much time, we could consider investing in some training on those topics to get them up to speed independently. Once that foundation is laid, I think our pairing sessions could go much faster (or potentially be eliminated altogether). Alternatively, we could try pairing them with somebody else on the team -- it's possible that I'm not explaining things in a way that works for them."
Give them a lot of grace and focus on leveling up the team as a whole, rather than remedying your personal situation. You'll likely get more engagement from your manager that way, since your manager ostensibly _also_ wants to level up the team as a whole.
I used yadm for a while. I switched to Chezmoi (https://www.chezmoi.io) though. Same ideas, but much better execution IMO.
It's unlikely that a given team/workplace is going to roll out dev tooling that is just a pile of elisp. With VS Code, you can drop a couple of JSON files into your project, commit and push them, and then everyone has a preconfigured set of tools that match the needs of that project.
1. I don't really want to bother with a DSL for configuring my editor (even if the language is usable outside of that context for other things)
2. I don't have time to bother with maintaining extensive configuration to get the level of code completion/refactoring/etc that I expect from a modern IDE (nor do I want to have to stop what I'm trying to work on to debug a problem with my config)
3. I don't want to have to research various plugins and stuff to provide functionality that I get out of the box with VS Code (or other editors)
4. I don't want to have a bespoke environment that only I understand when I'm trying to collaborate with my teammates
Don't get me wrong: I think digging into emacs and/or (neo)vim is a valuable thing to do and that everybody probably *should* do it at some point (even if only as an academic exercise), but to assert that they are a viable path for everyone is ignoring the reality that some people simply aren't interested in investing that time/effort into getting their tools working.
One can argue whether or not that stance is a good one or not, but you're just debating personal preferences and priorities at that point.
The problem that I (and many business owners) are solving for right now is not one of federal policy, but rather an economic one: I like to have food on the table to eat. I care very little about whether or not I'm doing that in a way that satisfies open source zealots.
If there's an open source option that lets me do what I need to do in an equal or better way, then sure: happy to go that route. But I'm not doing something in a clunky, nonstandard way just for the lulz.
Also check out the RPG Maker bundle. That's pretty point-and-click. You can have something basic up and running in a couple minutes (literally just paint your tiles onto a map and click Go and you'll have a little jrpg). If you use the newest version, you can script it in Javascript. One major selling point here is that their "runtime package" (RTP) comes with a TON of game assets to use, so you don't have to track down/make art if you don't want to (you can, but I often get blocked on art when I'm playing with game dev). https://www.humblebundle.com/software/gotcha-gotcha-presents...
GBStudio is another good (free) one to look at. It's point and click for the most part and if you get a flash cart, you can play your game on a real Gameboy. Definitely not gonna be the most flashy, but it's a good exercise in making something fun with limited resources available. https://www.gbstudio.dev
GDevelop is another no-/low-code option: https://gdevelop.io
Defold is another scripting-heavy option (Lua): https://defold.com
https://www.lesswrong.com/posts/E4cKD9iTWHaE7f3AJ/melatonin-...
I sort of see it the same way as "just install Linux Mint, it's great, you'll love it", but when something doesn't work, it's "oh yeah, just open the terminal and ________": opening the terminal is the _last_ thing people want to do if they just wanna read their email or whatever.
Addressing your argument directly though: you know that if you spin up a Postgres database for your app, you need to dump the database to disk to back it up (or if you wanna get fancy, you can do a delta from the last backup + a full backup periodically). Anytime a Postgres database exists, you know the steps you need to take to backup that service.
Same with persistent file storage on disk: if you have a directory of files, you need a snapshot of all of those files.
Each _service_ can know how to back itself up. If you tell a Dokku _app_ to back itself up, what you really mean is that each _service_ attached to that app should do whatever it needs to do to create a backup. Then, dokku only needs to collate all of the various backup outputs, include a copy of the git repository that drives the app, tar/zstd it, and write it to disk.
As you pointed out, the user should probably be able to control the backup cadence, where those backups are shipped off to, the retention period, whether or not they are encrypted, etc, but the actual mechanics of performing a backup aren't exactly rocket science. All of the user configurable values can have reasonable defaults too -- they can/should Just Work (tm). There's value in having that work OOTB even if the backups are just being written to disk on the actual Dokku machine somewhere.