Kissaki @ Kissaki @programming.dev

[@GitHub](https://github.com/Kissaki), [website](https://kcode.de/)

---

Read more

Posts

27

Comments

447

Joined

2 yr. ago

https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell

JSON is a much simpler (and consequently safer) format. It's also more universally supported.

YAML (or TOML) is decent for a manually read and written configuration. But for a scraper output for storage and follow-up workflows being through code parsing anyway, I would go for JSON.

I think I need an AI to parse these confusing graphs and images for me.

Infrastructure configuration that is automatically applied to the cloud infrastructure. Like starting and stopping new instances and services, changing connections between them, etc. (I assume anyway.)

If it's the one that makes the most sense to you then do it.

Even if the job market is at a low, I doubt other industries fare much better. If you'll be a good dev you'll likely be in good demand. (Even then job hunting may be a hassle, but I doubt that's different elsewhere.)

Go for it! It's not like you're stuck on that road forever anyway.

Not much more than the stock images we had before. When they're added to articles, most of the time, they added nothing but noise and wasted layout space the same way. It's just that the image is generated, sometimes [even more] silly now.

What makes GitLab CI better than GitHub Actions in your eyes?

I've not extensively used either, and GitLab CI has been a while, but they felt pretty similar. I had put them into the same category.

We use Jenkins at work. I administrate it. For the most part, I find it horrendous.

You like the marketplace? I dislike it. Or at least its form. I appreciate that there is sharing of actions.

But I dislike having to navigate between repo and marketplace pages. I dislike that I have to assess who publishes them and inspect whether they and the code are trustworthy, and I have to assess risk or whether to copy or extract the relevant code. (And then you have to add and configure via text and magic strings and look up params elsewhere which of course is a consequence of the tech, not a fault of the marketplace itself.)

I feel it adds so much indirection and diffusion it's hard to do good trustworthy actions/code well. Which if course stands against it's usefulness of sharing workflows and actions. I know I'm more concerned and more thorough with that stuff than most people.

I would dislike the first/referenced commit description as verbose as well. It describes a user or change drafting journey without ever saying concisely or separately what the commit actually does and why. If it at least had that summary up top in a first block or separated with --- separator it'd be much better.

I like the first part of the suggested alternative but I would never put a discovery journey into the commit message, or a "an hour of my life wasted". I would put them in a MR comment - or separated block in the MR description with the intention of it not becoming part of the merge commit description.

The journey is not relevant to the code and changes. When you think of looking at it one year later, you can see the value of a description of the change, but I don't see value in the discovery journey. The journey is more relevant in team-knowledge and workflow of how to work with the code base, and inter-personal team building.

Too much bloat of irrelevant information diminishes discoverability and conciseness of descriptive and useful information. It's noise.

Me using stars * for italic which renders italic in GitLab but as bold in TortoiseGit

I would hate to have to open Jira tickets to be able to understand code or code changes in Git history.

I guess it depends on the quality of the summary. And how usable your issue system is.

I'm sure I would continue to feel uncomfortable though, about the code and history itself not being self-describing. Issue systems change, become unreachable, etc.

I hate the default merge commits. I got quite frustrated when a FOSS project rejected (or didn't come to a conclusion) my proposal for merge commits to also follow the commit formatting guidelines.

The cherry on top is merge commits describing which branch is being merged. But the branch disappears with that merge. I consider it worthless. The branch name is a name of the drafting process. There is no value to it when it lands.

I'm fine with squash merges for one commit. But otherwise, I consider structuring changes into commits structure too.

My team merges with merge commits which hold the MR description as a commit description, and MR title as commit title.

Individual commits are retained and can describe individual changes, while the MR and merge commit describe the whole changeset.

It's a very interactive-rebase-heavy workflow (for commit cleanups/structuring when changes are added in review), but it works very well for us.

It can't be the terminal that decides what inhibits and what doesn't. It must be the user or programs themselves.

How would implementing it in the terminal rather than shell look like? As a user choice? I don't see how that's reasonably possible.

Reading the other comments it seems like there's already inhibit commands.

If the shell does not provide a command or alias, or they can't because the inhibit API is system dependent, it's on the user to define. The user could define a fg alias or command, fg for foreground, which executes the command with inhibition.

🤷 This didn't point out anything that's not a technical consequence and Microsoft planned for.

The overall ecosystem migration is not simple because of prevalence and variance in use, but it's still a huge net positive in my eyes.

I wouldn't call it messy. It's planned out, and the kind of process and concerns most senior devs are familiar with from any kind of tech migration. It's pretty clear with clear and well-defined concerns and solutions in my eyes.

this project was created due to wanting to give control of communication and data back to the people

The "giving control of communication" goal seems to contradict the "viewer automatically shares without a choice" and the dependence on good-intent node owners not moderating their node content.

If a node owner hosts a community, what prevents them from moderating that community?

I think calling that vibe coding is a very unfitting term. I haven't seen it called that before.

Maybe they're under rated because the stack expands downwards the call chain? You could say they're down under. /s

!meta@programming.dev

This is a community for discussing things about programming.dev itself. Things like announcements, site help posts, site questions, etc. are all welcome here.

I search with duckduckgo and the first results seem reasonable

Here's a signature and description https://www.khronos.org/opengl/wiki/Creating_an_OpenGL_Context_(WGL)#Create_Context_with_Attributes - khronos is publisher of OpenGL

here's the function I presume without attributes, so should be helpful to relate and compare https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-wglcreatecontext