I'm working on something very similar, but I've found that if I'm not doing the work - I forget what has been set up and how its running a lot faster.
For example - I have ZFS running with a 5-bay HDD enclosure, and I honestly can't remember any of the rules about import-ing / export-ing to stop / start / add / remove pools etc.
I have to write many clear notes, and store them in a place where future me will find them - otherwise the system gets very flaky through my inability to remember what's active and what isn't. Running the service and having total control is fun, but it's a responsibility too
This is the reason one should always ask the LLM to create scripts to complete the task.
Asking it to do things is fine, but as you stated you will forget. If you ask the LLM to do something, but always using a script first, and if you ask: 'Create a well documented shell script to <your question here>', you will have auto documentation.
One could go one step further and ask it to create a documented terraform/ansible/whatever tooling setup you prefer.
If you need to run the command once, you can now run it again in the future.
It's very tempting to just paste some commands (or ask AI to do it) but writing simple scripts like this is an amazing solution to these kinds of problems.
Even if the scripts get outdated and no longer work (maybe it's a new version of X) it'll give you a snapshot of what was done before.
I had the same thoughts a few months ago, and then someone told me Atuin Desktop is made for DevOps and the likes, in order to scale manual and repetitive operations accross many teams. This made sense to me.
We have CI actions we use to configure and deploy dev namespaces. We document a bunch of steps for these actions in a doc, including situational tweaks. I could see this being a great replacement for that, given the right integrations.
One of the main things we’re aiming to do here is make these manual processes much less manual! I’m a big believer in automating things gradually, which runbooks enable
Apparently if a light-bulb blows at a station, two different contractors need to be called - one company has a contract for replacing consumables while another has a contract for repairing faults.
Hijacked? no. For me this demonstrates the temporal differences between the web and the real world.
Books are solid things that will be here for a long time. Websites are transitory, ethereal and likely to change. It's clearly ok to reference a book from a website, but books that reference websites - yeuch. It reminds me of those stacks of hard-copy programming manuals targeting specific versions of a language now obsolete.
When you don't understand this you end up in this kind of situation. If you don't renew your domain, you might lose it (as the author and publisher are now finding out). I expect legal proceedings will fail miserably, and that a nice fat bung will probably solve the problem immediately.
> Doing the smallest and easiest solution to a problem as a way to get to know the full scope and then iterating after that if needs be is by far the best solution (for me).
100% -- this is YAGNI (or you-aint-gonna-need-it) and should be among the first things you think about when starting a new project.
Not patronising, this was exactly my first (and off-topic) thought as well.
We have lived in our house for +15 years and we still regularly find small fluorescent yellow ball bearings in the garden soil from the previous owners family. These things are here to stay
While we're here - I've gained a lot from "Data Analysis: A Bayesian Tutorial" by DS Sivia and J Skilling. It's a graduate level text, and I found the chapters very concise and the subject well-laid out. It was one of those books that gave me continuous insight and fresh inspiration - even though it's more than 10 years old.
In many non-US countries once hired there are employment rights. You cannot simply "kick them out if they dont fit ur needs". Isn't it preferable and less stressful for everyone if you can find the right person without having to hire and fire others first?
Depending on the European country, there is a probation period between 3 to 6 months, where any of the parties can cancel the relationship at any time, usually 1 week notice, unless it is really bad.
That should be more than enough to assess if someone is fit for the job.
How does an employer distinguish a worker who is trying hard only because he is on probation from a worker who will continue to try hard after the probation period ends?
If they try hard for 6 months during probation, then congrats on having a motivated dev for 6 months. If they fall off hard after, kick them out. It's only 3 months of salary. Compare that to thesalary and hiring process of finding a good dev, which is more expensive in many cases.
I'm not expressing an opinion on live-coding interviews or the choice between them and
probationary periods. I'm changing the subject away from the original subject
-- or rather I would be if "just hire devs and kick them out if they dont fit
ur needs" hadn't already done so.
I was just pointing out that your "that wouldn’t be caught in a live-coding interview either" does not shed any additional light
on the topic I personally am interested in, namely, the choice between a free
market in labor and legal regime that grant employees some job security.
Coding tests aren't filtering for people who work hard, they're filtering for people who know how to code. Whether they will work hard on the job seems like an orthogonal question?
They don't but usually wages are scaled to average. So So average output will still be what is expected. Really bad ones well, you start giving notices. And then with enough evidence you can terminate contract.
You can't, in the same way you can't distinguish a romantic partner who is using you from one who genuinely likes you. Because clairvoyance is not real.
In many non-US countries there is also a probation period before full employment rights kick in, allowing employers to fire new hires without reason, so definitely you can "kick them out if they don't fit your needs" in many countries.
Yes, this was common web design advice in the mid 90s, though often people's first response was to simply replace "Click here to..." with "Follow this link to...", which was almost as bad.
Fixing those was a large part of my life whilst working for a web design agency during the school holidays circa 1996-97 (providing plenty of incentive to learn find/grep/sed/perl!)
I guess this 2001 W3C 'Tips for Webmasters' page was merely stating the commonly-accepted best practice at the time.
Yes, most people understand how to navigate around the jankiness...
For example, most Windows programs have "File" as the first menu item. How do I exit? Go to File, the bottom option is usually "Exit". Does that make sense? No, why is "Exit" a File-related option? Why is it like that? Because it's always been like that.
Want to learn about the program? Go to Help > About.
Some more geniuses even got involved and thought "If the user wants to edit preferences, well, they can go to the menu option Edit, and find Preferences. Never mind that Edit is otherwise filled with document related functions like Cut, Copy, and Paste!"
Meanwhile, on GNOME, there is no standard menubar so good look figuring out which one of the icon-only buttons in the headerbar has the dropdown menu with the action that you want.
Edit -> preferences makes sense because you're editing your preferences. File ->
Settings makes no sense. Help -> Options makes even less sense. Help -> KEYBOARD SHORTCUTS is just insane to me.
I somehow think it would be more janky if the "exit" or the "preferences" items were in some random menu. I've never cared that "exit" doesn't seem to fit with "file" because it's always seemed more convenient for me that it's always in the same place.
Yes, it's janky but familiar. On the phone you'll see a "Click here" and know to use your thumb to touch the area of the screen to do whatever action is behind that, on the text-based browser you know you can tab to that "Click here" text and hit Enter to navigate. If a kid saw this you'd have to explain to them the historical context of desktop computers and mice.
Just because you're used to the jank doesn't mean it's the best design.
As sibling comment says, on the Mac the first menu item is about the app. App -> Preferences, App -> Exit, wouldn't such a convention make more sense?
I mean, on a Mac, there's always a menu for the current app as the first item, titled after the app. If I want to quit Slack, I open the Slack menu. Which makes a good amount of sense.
For example - I have ZFS running with a 5-bay HDD enclosure, and I honestly can't remember any of the rules about import-ing / export-ing to stop / start / add / remove pools etc.
I have to write many clear notes, and store them in a place where future me will find them - otherwise the system gets very flaky through my inability to remember what's active and what isn't. Running the service and having total control is fun, but it's a responsibility too
reply