Maybe you want to scan for FIXME:
too?
What’s the nature of the temporary system?
I would consider; remote/temporary systems are not necessarily mine, or setup is not worth it given my concerns on it; There’s different options to install or configure existing shells, I could take my config with me; if it’s a temporary system maybe it’s based on a template that could be adjusted, or auto-setup scripts could be adjusted
It would depend on how much I use it, how much I miss my setup, or how irritated I get because of missing stuff, and considerations of whether it’s worth it (to me).
I’m someone who adjusts their environment to their needs and wants, moreso than other colleagues I see. Many people seem to simply accept existing environments and (to me) annoyances.
When I remote into servers, it’s not typically where I would use much Nushell functionality. Bash and vim is good enough for those things, with just a little bit of configuration. I don’t plan on installing it on work servers, but have recently thought I may install it on my own server for convenience.
Doesn’t help that it’s a multi-page document…
Persistent domain entity, Proto-persistent domain entity, View model, ,
What the heck… Yeah, I wouldn’t want to use that either. While it may be a formalization, it seems like it would significantly increase complexity and overhead. That can’t be worth it unless it’s a huge enterprise system that has to work with generalized object types across teams or something.
I hadn’t heard of Restful Objects before.
I didn’t quite follow.
They’re using htmx, make errors, and learning something new about using it?
That’s like using any new tech though, right? Or - depending on the devs - happens even with established tech.
I’ve never seen htmx in production. I find it interesting though and want to explore using it. That won’t be at work though. :)
I found the dropping of actions quite surprising as well. I would suspect we could return the links with a disabled attribute? If they should be displayed but not accessible/triggerable.
We could have called them HTTP APIs.
No, it doesn’t mean only humans can interact with it.
The key point [of classical REST] is that responses are self-contained self-describing. Requesting a resource response tells you what actions you can take on it. There is no need for application domain knowledge, implicitly or separately-explicitly shared knowledge.
Some HTTP web apis offer links in their JSON responses for example. Like previous and next page/ref on paging/sectioning/cursor. Or links to other resources. I don’t think I’ve ever seen possible resource actions/operations be included though. Which is what the original REST would demand.
That’s how I understood it anyway.
Their suggestion of using HTML rather than JSON is mainly driven by their htmx approach, which the project and website is about. Throughout this article though, they always leave open which data form is actually used. In your quoted text they say “for example”. In a later example, they show how JSON with hyperlinks could look like. (But then you need knowledge about that generalized meta structure.)
I’ve used it at work. But the manual management/maintenance of a commit list makes it practically infeasible. I’ve use it for bit cleanup commits, but not since. When blaming, the previous revision is just one click away anyway. The maintenance doesn’t seem worth the effort.
I guess a commit message tag and script that generates it automatically could make it viable. But I’ve not found the need to yet.
Installable alternative: https://zealdocs.org/
Given that it is high level, I assume you did not want to include this. I’ll mention it here in a comment either way. Text form in the commit message.
I really like using conventional commit messages and introduced it in my projects. We defined a few types, and more leniently choose optional scopes. It’s very useful for categorizing and skimming through commit lists, and for generating changelogs/release notes. `fix(account): Use correct hasing xy"
Consistent imperative form is important to me too. The commit message examples talks about “Summary of changes”, which has no verb, and so, may mislead to a different undesirable form of summarizing changes. (“Change xy” instead of “changed xy” or “[now] does xy [at runtime]” or “did z”.)
I didn’t fully read it, only skimmed, so excuse me if I missed mentions of the commit message text form. It seems very elaborate otherwise.
My browser has a default font size of 18 set. The site overrides that with a default base font size of 12px, then increases it to 13px for content text. That’s way too small for me on my screen. At least to read it comfortably. Or for people who need more accessible text/font.
each function has its own independent metal toggle switch
one steering wheel to steer left, and one to steer to the right
they want to push a lot of buttons on those controls
LOL
Even with a lot of buttons available, good videogame controls are simple and narrow. Natural combinations add depth without overcomplicating things.
Damn, that’s a long list. Looks like a lot of work to collect and prepare.
I was looking for more of an overview of it and selected them from the headlines:
let a = ''
for (let x of document.querySelectorAll('h3 a[title]')) a += x.title + "\n"
a
deleted by creator
libsass.so: cannot open shared object file: No such file or directory (LoadError)
You’re missing the SASS library
If Markdown formatting is enough for you, I would look into using a static site generator, like Hugo or Jekyll.
If you want to keep your existing content as static files but same website skeleton and layout instead of copying and editing files you’ll copy one and create the layout template. Then content and new posts and pages can be generated from Markdown files. If you set up CI they won’t need to run Hugo or what you’re using, only push the Markdown files to your Git repository.
Whatever you want to do primarily depends on: Your formatting, styling, functionality, and interfacing needs for the editor, and what you’re willing to use or invest for setup.
Hugo runs from a single binary. The source layout is reasonable. With a single layout the folder structure doesn’t have to be complex.
I’m not very familiar with alternative [Markdown] static site generators.
You’re good to keep your skepticism. If you trust them, the ones creating the tutorial to have vetted to a degree, or that a very popular package like that is vetted to a reasonable degree, you’ll just go ahead with it. (Like most people do without questioning it.)
You’ll need considerable experience and insight to do good, reasonable risk assessment. Without that, you can either trust and hope in others, or skip the ecosystem and look for alternative technologies.
It’s also worth noting that your potential impact is considerable lower if you’re only doing local test and development work, not publishing or publicly serving anything. I’m not personally familiar if or to what degree running arbitrary local commands has been limited in the npm ecosystem by now.
I let them ripe for 10 years so I can then concentrate on older bugs.
https://codeberg.org/lig/todo-md/issues/4
I didn’t create one because I won’t be using the project, but suggested it here for your consideration. :)
Outside of work-in-progress or exploration branches, I don’t commit or merge TODOs. Typically, I consider them merge/land blockers. Because most of the time, they’re never resolved. And in that case, I much prefer documentation and statements; reasoning of why it is the way it is, or opportunities.