Kissaki

@Kissaki@programming.dev

This profile is from a federated server and may be incomplete. For a complete list of posts, browse on the original instance.

Kissaki ,

When something hits you in the face you turn blue. This essentially hits you in the face, and matches that color.

Kissaki ,

Ubuntu LTS.

It has the option for PPAs when the distro doesn't offer packages or recent package updates but the upstream project does.

It's a well-established and stable distro.

Kissaki ,

https://nobaraproject.org/

The Nobara Project, to put it simply, is a modified version of Fedora Linux with user-friendly fixes added to it. Fedora is a very good workstation OS, however, anything involving any kind of 3rd party or proprietary packages is usually absent from a fresh install. A typical point and click user can often struggle with how to get a lot of things working beyond the basic browser and office documents that come with the OS without having to take extra time to search documentation. Some of the important things that are missing from Fedora, especially with regards to gaming include WINE dependencies, obs-studio, 3rd party codec packages such as those for gstreamer, 3rd party drivers such as NVIDIA drivers, and even small package fixes here and there.

Kissaki ,

When you copy a file onto the Void, does it disappear?

Kissaki ,

If working around it is an option, you could switch from https to ssh protocol.

Kissaki ,

Depends on what I want or need to "understand".

I've worked for many years on a project (it's a whole project ecosystem tbh with multiple projects; desktop winforms app, server app, SQL server, asp.net MVC app, asp.net blazor app, mobile wpf app, sync service app). On the main project (client + server) I haven't visited one major area, and another I confidently know that it's not understandable to me without specific deep effort.

I recently had to work on the latter. I take a localized approach. Explore what I have to do, without opening the full scoped understanding that'd lead me to architecture refacs. I write out the method call stacks to get an overview of who calls what when. To then know what I have to inspect and analyze further.

I take notes where necessary, or improve and comment code where appropriate for better understanding and obviousness.

I create documentation - about concepts and architecture as appropriate and necessary.

Code should be obvious and intuitive. Concept docs should document the broader concepts.

When those concept docs exist, those are what you look at to understand app intention and behavior. And it should give you an introduction to architecture. From there, exploring the code should be self-explanatory (but may require specific, repeated, and iterative analysis). And I take notes about what's relevant and I need for understanding or task.

Afterwards, those notes should have, or should then integrate into the code base or docs, or be determined irrelevant for that. If I had to write them out and down, it's more likely they should be part of something than not.

Kissaki ,

In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates. ®

Random trademark symbol. What's the registered trademark here? The dot? "advocates"?

Kissaki ,

How does it display emotes in the terminal? Does it include FFZ, 7tv, BTTV emotes?

Kissaki ,

Is that limited to the kitty terminal? I don't see any compatibility notes on Kitty Graphics Protocol nor your TUI project - which given the TUI label I would expect to work on any terminal?

Kissaki ,

I'm glad I was able to establish a very mindful and structured approach to Git history in my team and project.

Kissaki ,

There is no other CLI tool like Git. But

Shell or Bash has various alternative shells.

Vim has numerous plugins and alternatives/extensions.

Linux distributions are wide and varied, forking out.

Kissaki ,

I think the fundamental difference is that Git is a CLI tool. But that's not how or where people use and want to use it. So obviously various interfaces are being created. It's not alternative CLI that are created. It's UIs and GUI interfaces. For a lack of a [more-than-barebone] official one.

Shells remain CLI. Distros are also technically/technologically driven.

Maybe the better analogy is that with vim and nano, we see many text editors and IDEs with GUIs.

Viable Alternative for ZSH as the interactive shell?

So I'm currently using zsh + oh my zsh, and have been using it for some years now. It's good, it has amazing features (via plugins) and overall I'm happy with it. But lately it has become laggy for me (probably because of plugins) and I want to see if there's any other shell with features like ZSH but faster and lighter?...

Kissaki ,

It's not POSIX either, but I'll answer your closing question: My current shell of preference is Nushell.

Kissaki ,

Yeah. But OP specifically mentioned them disliking Fish because it's not POSIX.

mpicreates , to Godot
@mpicreates@mastodon.social avatar

I made a really simple 2D platformer yesterday using @godot and following a tutorial.

It's all assets I downloaded and steps I followed, but it's something I never thought I'd actually be able to do!

It was interesting and I definitely want to learn more in the future!

This is the most fulfilled I've felt in months.

Kissaki ,
Kissaki ,

I don't see how it solves the mentioned issues. Instead, federation introduces new issues of complexity, multi-layered moderation, and potential for distributed inefficiency, confusion, or more malicious attacks.

I think we can see on Lemmy some of the problems it introduces. But for an Encyclopedia, which is supposed to be a source of truth, I think it's much worse.

If you depend on instance admins as curators, it's not that different from Wikipedia roles, which at least has open governance and elections.

They say other projects didn't reach critical mass. I don't think spreading your contributors thin - even while connecting them to some dynamic degree - is how you reach critical mass.

Just placed 3rd at my first game jam!

Had to share with this community, I decided for my second game to just rip off the band-aid and I entered a game jam targeted at beginners. I placed 3rd - with 1st and 2nd going to more seasoned game developers. I never imagined that, going in, I would be on the pedestal. I just have to thank everyone that participates in game...

Kissaki , (edited )

My context: I'm in a small ~30 software company. We do various projects for various customers. We're close to the machine sector, although my team is not. I'm lead in a small 3-person developer team/continuous project.

I write unit tests when I want to verify things. When I'm in somewhat low, algorithmic, coding behavior, interfacing areas.

I would write more and against our interfaces if those were exposed to someone or something. If it needs that stability and verification.

Our tests are mainly manually (mostly user-/UI-/use-interface-centric), and we have data restrictions and automated reporting data consistency validations. (Our project is very data-centric.)

it’s not practical for our size and the business would allow us to slow down for that

Tests are an investment. A slowdown in implementing tests will increase maintainability and stability down the line. Which could already be before delivering (reviews, before merge or before delivery issues being noticed).

It may very well be that they wouldn't even slow you down, because they could lead you to a more thought out implementation and interfacing. Or noticing issues before they hit review, test, or production.

If you have a project that will be maintained then it's not a question of slowing down but of are you willing to pay more (effort, complexity, money, instability, consequential dissatisfaction) down the line for possibly earlier deliverables?

If tests would make sense and you don't implement them then it's technical debt you are incurring. It's not sound development or engineering practice. Which should require a conscious decision about that fact, and awareness on the cost of not adding tests.

How common automated testing is - I don't know. I think many developers will take shortcuts when they can. Many are not thorough in that way. And give in to short-sighted time pressure and fallacy.

How do I not stop feeling like I am doing nothing outside work?

I am professionally a software developer for 8 years and I simply don't have ideas for personal projects (Can't find any problem that I can fix with programming). At times I feel like that's natural and I shouldn't worry about it. But on the other hand, I do like to imagine having something personal that I can work on so that...

Kissaki ,

I've recently gotten into codewars.com a bit. (Not for a lack of personal projects.) I can recommend you try it.

The kind of projects that could fit depends on various things. What kind of projects would be of interest to you? Visual? 3D rendering? Algorithms? Utilities? Desktop software? Web? Known or new technologies? Which ones?

  • Implement a binary data serializer - for example for CBOR or BSON
  • Implement fractal rendering
  • Implement a checksum utility
  • Implement a personal website
Kissaki ,

Whatever you do, don’t start down the path of […] Started messing with […] in December and it has been the bittersweet curse of a never ending things to do.

Sounds like… any and every project? 😅

Kissaki ,

I’m not sure I understand what issue Linus et al. are trying to solve. If the full hash is used whenever a commit reference is saved somewhere, then why does it matter how core.abbrev is configured?

What are you referring to?

The article is about abbreviated forms, not full hashes. The Linus quote is specifically about abbreviation.

[Linus] He recommends kernel developers use 12 characters

For a large code base you can expect to further grow continuously for a long time, it makes sense to already use more than a minimum abbreviation so that you references remain unique, even if a decades time.

Configuring a wider and explicit abbreviation width that will remain constant is preferable because the displayed references are what you will copy and reference. It doesn't make sense to work with shorter abbreviations locally, but wider abbreviations when communicating with others. It'd be a hassle to translate and risky to miss doing.

Kissaki ,

I've been using TortoiseGit since the beginning. Nothing ever came close for me.

I in the log view I have overview, filters, and all actions at hand.

Kissaki ,

It’s a fundamentally visual problem

In what way do you mean git versioning is fundamentally visual?

Or do you mean understanding it or visualising it? The data and its relationships?

Kissaki ,

No, there is not.

Mirroring git repos themselves can work with automation. Anything beyond that has serious drawbacks or complexity or won't work.

As for your key auth (git client auth), one key for authentication is sufficient to use across all platforms.

Kissaki ,

I don't think I can adequately give a decisive answer to that. I'm not in your shoes and lack full context.

I don't think any potential future employer will see you working on language modes a downside. You worked with Java before, productively, with experience. So you know your Java. You then worked on LLM, which shows flexibility and is additional, possibly useful experience.

  • You could give it a try, and a timeframe, to see where it goes.
  • Consider that it may be a fad that may disappear again, and your company may go back to Java. If it's CEO driven like that, where it can make huge changes in how it's set up, it can happen again.
  • Consider whether you can talk to team leads or HR, considering your perspective within the company, your goals and interests, and what the company can provide in that regard, and what it won't.
  • Salary. Coworkers. Work environment. Work satisfaction. Technological interest. It's all things to consider. Unless it's really significant, it won't be one thing overpowering all the others.
  • You can look for alternatives while continuing to work. Either to sight what your alternatives are, or actively to switch away if and when you find something more fitting with acceptable consequences.

In the end, a switch may require a decisive decision, even if you're not sure. But staying and seeing where it goes is not bad either. Looking for alternatives is safe, and at the same time may spark interest elsewhere.

Kissaki ,

The weblink at the bottom to an Atlassian article is a dead link. Sounds about right for Atlassian I guess. Can't keep something running for 9 years.

Kissaki ,

in detail

Learn […] how they streamline the development.

proceeds to give generic minimal broad overview.

This website should be banned. Nothing good for the community will come out of this content farm.

Kissaki ,

FF124, Windows; What I see is grey and a loading icon.

Have you opened the Browser Console?

downloadable font: Glyph bbox was incorrect

While one would not expect that to cause such issues, depending on if you're using a SPA or what kind of bootstrapping you use, or a Firefox consequential issue, it may. What happens if you skip web fonts?

I can open the browser console, and I can context menu inspect elements, and it selects them in the inspector. So it seems like the DOM is being rendered and laid out, to an interactable level.

When I open CTRL+SHIFT+M it looks very funky and broken. No border, nothing rendered; only the resize handle, which remains usable. Using different Window to compare, there should be a border and border shadow. This makes me come back to the font issue, and makes me wonder if trying to render a faulty font brings Firefox into a broken render state.

Kissaki ,

They're mixing and messing definitions and concepts and separation together and then get confused because of it. It describes a behavior analysis discovery but lacks the useful, valid discovery. I don't think this is useful for others to read, and detrimental for git newbies, because it's more difficult and confusing than helpful.

  • git says HEAD defines the current branch
  • rebase is a process operating on commits and branches - it breaks out of the simple "current repository state" because there's a process and process state around that. They notice things being different, but fail to elevate their view or discover that they have to interpret it differently.
  • bare repository has no workspace - as such, workspace commands won't work, and there is no workspace current branch. HEAD defines the default/main branch.
Kissaki ,

you can completely understand how the page will look just by reading the html

You lose being able to read meaning and structure though, and you also lose technical accessibility.

I like to add css hacks to websites. But I can't if they don't have useful, identifying, and stable selectors.

Kissaki ,

Static typically refers to static pages. Which can have dynamic elements, but no backend.

IE: you can’t have a contact form without paying a 3rd party.

Unless you open an email client or other url to forward the contracting I don't consider that (purely) static anymore.

Given that, I'm not sure what you even want "static gen" for? You may be looking for the wrong thing.

Kissaki ,

If that's your hope for static generating, "contact form with backend" goes against those goals. It's an important requirement shifting the entire viability and weighing of platforms and hosters.

Kissaki ,

I think this post makes an unnecessary distinction and unnecessarily leaves their connection open, making it more complex.

The baseline and reasoning should always be the HEAD, represented by .git/HEAD. Describing what they call a "revision parameter" or output should always refer to and be defined by that baseline. Because that's what it uses and refers to.

Instead of "closely related" we can say one refers to the other. The context on "ways git uses HEAD in its output" implies/seems to nudge to me that it's something different; but again, a HEAD label references HEAD. There's no variance in what HEAD refers to.

HEAD -> sha1 (commit)                          => detached head (not on any branch)
HEAD -> refs/heads/branchname -> sha1 (commit) => on branch branchname

All of these things (HEAD, HEAD^^^, HEAD@[2}) are called “revision parameters”. They’re documented in man gitrevisions, and Git will try to resolve them to a commit ID.

While they listed a commit range in the example, they fail to mention it here. A revision range does not resolve to only one commit. ("Specifying ranges" is documented on the same git man page.)


For example, git talks about “detached HEAD state”, but never about “attached HEAD state” – git’s documentation never uses the term “attached” at all to refer to HEAD. And git talks about being “on” a branch, but never “not on” a branch.

I think it's a good choice to not unnecessarily complicate default mode and usage. Detached HEAD is the exceptional state, and not commonly used.

So it’s very hard to guess that on branch main is actually the opposite of HEAD detached. How is the user supposed to guess that HEAD detached has anything to do with branches at all, or that “on branch main” has anything to do with HEAD?

I can agree it's not obvious though. It requires understanding of what HEAD actually is - which is useful for the other things you list too (specifying revisions and understanding output).

I'm not sure if there's a good or better way for introducing the user to it though. It's inherent tool complexity. And I don't think calling every HEAD attached when it points to a branch is verbose to the point of being detrimental.


I don't find the HEAD in diffs between merge and rebase confusing. When I rebase commits I am always aware of the replay activity. (I mainly use TortoiseGit where it is always obvious through updating rebase progress.)

Displaying the original HEAD before the rebase started would be wrong and even more confusing. Because that HEAD and commit is no longer part of any of the changes. You are on a different base, and you are cherry picking onto it.

Kissaki ,

Detached HEAD meaning that the HEAD ref doesn’t point to the same commit as the branch ref that always follows the last commit in a development branch

IMO this is misleading, or incomplete.

HEAD is different from branches in that it can point to a commit or a branch. A branch always points to a commit.

When HEAD is in [branch] detached state, there is no branch to refer to/we can refer to. We are outside of branches.


From a use case perspective that may illustrate the difference:

When HEAD points to a branch, and I commit, I commit to that branch.

When HEAD points to a commit ([branch] detached HEAD), and I commit, I create a commit, and HEAD points to the new commit, but there is no branch pointing to it. (A followup is needed, e.g. creating a branch, or updating an existing branch, to keep the new commit discoverable even after we change what HEAD points to - e.g. by switching to a branch.)


I thought HEAD was just a ref

"refs" are stored in .git/refs/heads - but HEAD is not. In that sense, HEAD is not a ref like the others (branches and tags and whatever else you put there, like pull request references).

HEAD is either a reference or a reference to a reference. Branches are references.

Kissaki ,

I don't think I had a moment like that.

I discovered it, along with other DVCS when it came up, and looked into it and learned it. It was reasonable and intuitive enough for me. As far as I can remember anyway. (I don't have particular memories of that.)

Kissaki ,

whether it feels “correct” or if it is missing something

What's your goals? What are your concerns?

What specifically do you want impression or assessment on?

You created a blog, and created posts. That's blogging. If your goal was to blog, then "it" is "correct".

Kissaki ,

Yeah, keep writing, and remain mindful, maybe revisiting what you wrote and how you approach things every dozen.

As for ads, I doubt you'll make much, given that you're just starting out. For me it wouldn't be worth it to include. But whether it's there is secondary to content and layout.

Even without an audience or growth writing has upsides. Can be for yourself, but also support mindful or critical thinking, and being able to express and write in general.

Kissaki ,

Driving a train is engineering?

Kissaki ,

The term engineering is not about problem-solving, especially when differentiated from development. Engineering is about deliberate understanding and decision-making, about giving it an architecture, a structure.

You can develop without any structure, solving an issue, without understanding a bigger context or picture or behavior. But that's not engineering.

Kissaki ,

I see, TIL. That's different from Germany, where Ingenieur is a protected term.

Kissaki ,

To a degree, if pull requests are small enough, then yes.

Often, a changeset includes different aspects and concerns though, and individual commit messages allow you to document and reason them. Squashing makes you lose the concern separation.

When reviewing, even relatively simple changes separated into their concerns helps me a lot.

It's a matter of preference and necessity, and the changeset and it's environment at hand.

Kissaki ,

I don't have multi-user library maintenance experience in particular, but

I think a library with multiple users has to have a particular consideration for them.

  1. Make changes in a well-documented and obvious way
    1. Each release has a list of categorized changes (and if the lib has multiple concerns or sections, preferably sectioned by them too)
    2. Each release follows semantic versioning - break existing APIs (specifically obsoletion) only on major
    3. Preferably mark obsoletion one feature or major release before a removal release
    4. Consider timing of feature / major version releases so there's plannable time frames for users
  2. For internal company use, I would consider users close and small-number enough to think about direct feedback channels of needs and concerns and upgrade support (and maybe even pushing for them [at times])

I think "keeping all users in sync" is a hard ask that will likely cause conflict and frustration (on both sides). I don't know your company or project landscape though. Just as a general, most common expectation.

So between your two alternatives, I guess it's more of point 1? I don't think it should be "rapidly develop" though. I'm more thinking doing mindful "isolated" lib development with feedback channels, somewhat predictable planning, and documented release/upgrade changes.

If you're not doing mindful thorough release management, the "saved" effort will likely land elsewhere, and may very well be much higher.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • random
  • test
  • worldmews
  • mews
  • All magazines