Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)E

Ephera

@ Ephera @lemmy.ml

Posts
5
Comments
1330
Joined
6 yr. ago

  • What are you working on?

    Jump

  • Been hacking away for quite a while at basically a build tool/framework for Rust, which picks up where Cargo leaves things. So, it's really just a set of libraries for now, which you can use while writing your build scripts in Rust, to help with stuff like putting together a distribution archive, caching intermediate results or handling the automatic installation of CLIs you use in your scripts.

    Definitely has been an experience to build this. It feels like a magnitude more work to find generic solutions for this stuff, compared to just throwing it down for a single codebase.But it has also been rewarding, seeing builds becoming more robust and quicker in the other projects that I'm definitely also still developing and not just using as a testbed for my build tooling. 😅

  • What are you working on?

    Jump

  • The first chapter of the Rust-CLI book is IMHO a very good place to start for just learning how to build something useful. Of course, it does not replace building a project of your own, but might give you enough of a framework to fit your own ideas into.

  • PR: Linux.exe

    Jump

  • You have to click a random heading in the info section to the right of the code listing (or below it on mobile).

    I do also find GitHub's URLs are much more user-friendly than the GUI, though.

  • PR: Linux.exe

    Jump

  • PR: Linux.exe

    Jump

  • Forgejo has it exactly where @BootLoop@sh.itjust.works is saying, though.

    Like, yeah, it is still primarily a code hosting platform, but that doesn't mean the releases have to be in the most awkward place possible.

  • What you saying?

    Jump

  • Many years ago, a girl in our class was telling a friend and me a secret. Then she addressed my friend to say that it is a secret and he shouldn't tell it to others. My friend complained that he knew to keep it secret and why she wasn't addressing me as well. Then she said that I don't tell stuff like that to others.

    Yeah, ten seconds earlier, I was the one who suddenly realized that, oh right, it's a secret, when she addressed my friend.

    Like, no, I probably wouldn't have told it to anyone, but I feel like I got way too much credit, just because I'm not terribly talkative.

  • One Bad Boy

    Jump

  • Grab it from FlatHub or RPMFusion instead, if you want that...

  • Something about incentives

    Jump

  • Then you get other side-effects, like them ignoring or infinitely delaying tickets that are harder to solve. It's a somewhat universal rule of capitalism: As soon as there is a metric for success, the goal is to game that metric as much as possible, because that maximizes the supposed success while minimizing costs.

    You can try to define multiple metrics to make this more difficult. And you can set a higher target value than necessary, so that even with the gaming, it's still within an acceptable margin.But IMHO it's still better to just treat it as a cost of doing business than to invest lots of money to try to make it measurable in an attempt to reduce the money spent.

  • Something about incentives

    Jump

  • Well, yeah, you might just get pushed out by competitors who supposedly have much lower cost per solved ticket...

  • Something about incentives

    Jump

  • Yeah, I think, it's important to name and shame, because they actively avoid providing the service that they advertise, but I do also expect this to be a common pattern in the industry. If you actually solved problems and did so permanently, you'd be out of business very quickly. External support providers have an inherent interest for things to work as badly as possible, so long as it does not get their contract cancelled.

  • Something about incentives

    Jump

  • Oh man, my workplace switched to an external IT support company, InfoSys, which pulls basically the same scam.

    When you open a ticket, they immediately write something underneath – typically a question that's already answered in the ticket – because it shows up in their statistics as low response times.

    Then they'll do shit like split up your ticket into three new tickets for no good reason.

    And if you happen to be on holiday for a few days and therefore don't respond, they'll close your tickets due to inactivity.

    Then you have to open a new ticket and link to the old ticket, if you can still access it, and then re-answer the same braindead questions again.

    Basically, if it's something you can solve yourself, you should, because it will take more time to communicate back and forth with InfoSys.

  • Are there actually any good mobile games?

    Jump

  • Stringly typed

    Jump

  • Ah, yeah, very familiar with that article. 🙃

    It's definitely part of the reason why I like these really narrow types. But the other big reason is that your internal APIs start to look like this:

    It just makes it almost impossible to pass the wrong value into a parameter. You don't need to wonder, whether you should pass your port variable into a parameter called bind_port, if you introduced separate types BindPort and RemotePort for them.

    Of course, this is a somewhat extreme example. It's up to you to decide, whether you're likely to encounter multiple values of the same type and whether it's therefore helpful to make it impossible to confuse them.

  • Deleted

    Permanently Deleted

    Jump

  • Also not OP, but I find it makes it harder to see what's going on. Like, it's probably fine, if you've got good vision and are holding the phone straight on. But if your vision is impaired, including by outside factors like bright sunlight or having to use your phone at a weird angle, then it may make things harder than they should be...

  • The Theatre of Pull Requests and Code Review

    Jump

  • Last year, I was thrown into a senior role and having to do reviews for the first time. We also had to onboard two juniors from another team, who had no routine in structuring commits.

    We didn't have the capacity to get them up to speed on that, so every time they would submit a badly structured PR, where there was no story. I had to look at each individual line and decide whether it's good or bad, which is hell.Every single time, I would find stuff that was bad and then my feedback was just as useless, because I couldn't tell them where they took a wrong turn in their story. Instead, I had to basically provide them a diff with the required changes.

    After a few months, we talked about how they should structure commits again (i.e. smallest atomic change) and fuck me, it must have clicked for them at that point, because their next pull request was the first time that I was able to just merge the whole thing as-is.

    I imagine, it helped them a lot, too, to think about what is the smallest atomic change and to be able to test between those changes.But yeah, it was wild how different the experience for me was. I could just look at the commits and immediately knew that what they had changed made sense on a fundamental level.

    I had always intended to not be as nitpicky about the details, but if you have to piece together what they changed by looking at the details, that means you have to actively look away. This time around, I had hardly a reason to dive deep into the code, and could rather choose to look at commits, where I knew that the implementation details matter.

    It is possible that I actually did not notice as many bugs, but I went out of that review feeling a lot more confident that the code worked, because I knew that the bigger picture was correct.

  • crates.io: Malicious crates faster_log and async_println | Rust Blog

    Jump

  • Damn, expected something like this to happen or, well, be detected after the big NPM attacks.

  • How I, a non-developer, read the tutorial you, a developer, wrote for me, a beginner - annie's blog

    Jump

  • I mean, as it says at the end, this blog post is in good fun. It most definitely expresses frustration, but it also recognizes that perfect is the enemy of good, and that you already put in more effort than one can expect by writing a tutorial to begin with.

    I guess, my main takeaway is that you really don't need to bother writing up your life story. It will fly over the head of your readers, for sure. (Although a bit of context may still be important.)And you should probably spend a few more words, describing the actual steps, no matter how obvious those may seem to you.

  • Why Zig Feels More Practical Than Rust for Real-World CLI Tools

    Jump

  • Man, I don't know what kind of CLIs this guy is building, where you need to keep long-lived references around and whatnot.CLIs are typically quite easy to build in Rust, because in most cases, you just load your ~/.notes, iterate over the files/lines once, print out the result and then exit. I have a hard time coming up with a scenario where building an in-memory (!) tag index benefits you in a CLI.

  • Some thoughts on programming 3 years into full time

    Jump

  • As for When to abstract, you particularly want to deduplicate code that implements logic (as opposed to boilerplate code).It's much more likely for this kind of code to require changes or bug fixes over time and therefore for the separate versions to drift apart.

    I've also found that you should still lean strongly towards deduplicating code, because it isn't just you who needs to know to change both versions of a code snippet. Your colleagues need to know, too, including those who join the project later. And the chance of this working out as intended, is practically zero. If you have duplicated code, you need to assume that multiple versions of it will exist.