ben0x539

I don't think it would occur to me to write out Continuous Integration because it's basically a nonsense term if you don't know what it means anyway, it's not any less opaque than just CI. The problem isn't the shorthand here, but yeah it's probably good to spell it out anyway so when someone googles it they have more confidence they've found the right thing.

Can you control the timing of queries across two db instances well enough to expect the tables to be identical?

screenshot of finishing with 4 strokes / 6 par (tho my locked-in daily result was 14 strokes).

The video is bouncing the ball of a wall right at the start to make it jump over the wall, water, and corner behind the start, to skip most of the track.

https://i.imgur.com/PzlgXnD.png skill issue

edit: https://i.imgur.com/9xnntqB.mp4 fairly reliable trick shot

I imagine people will immediately patch out the auth requirement once the auth servers go away for good.

I bet we'd see a bunch of unexpected breakage in presumed-to-be-lower-level-than-http[s] infrastructure so that eg. your legacy IRC server goes down because it's running on rented hardware and the hosting provider's operations rely on some internal http services.

Say what you will about github-the-source-control-platform, github-the-unified-login-for-bugtrackers has been a huge success.

> edit: I removed the author’s name from this post

well, you didn't from the search query.

In your experience, is there a lot of contention over whether a given issue counts as a bug fix or a feature/improvement? In the article, some of the examples were saving people a few clicks in a frequent process, or updating documentation. Naively, I expect that in an environment where bug fixes get infinite priority, those wouldn't count as bugs, so they would potentially stick around forever too.

That is some "every element apart from helium and hydrogen is a metal" taxonomy!

You know that "Fachkräfte" doesn't mean immigrants, right?

Few things are truly forced upon me in life but walking away from everything that I don't like would be foolish. There is compromise everywhere and I don't think entering into a tradeoff means I'm not entitled to have opinions about the things I'm trading off.

I don't think the article sounds like someone didn't take the time to grasp the language. It sounds like it's talking about the kind of thing that really only grates on you after you've seriously used the language for a while.

Unfortunate that this page largely shills XLibre, the X fork by the guy who got ejected from contributing to Xorg when he landed a bunch of code that was blatantly untested, leading to tons of his commits getting reverted. Like, I am not a fan of Wayland, still using X on my machine, but from what I've seen of his posting, this guy isn't great PR for the "X is fine actually" camp.

I bet there's concerns with users who don't have a robust mental model of what applications/windows are currently alive or starting up or whatever just losing track of a window completely if it doesn't grab focus, and getting annoyed at programs seemingly failing to start up at all (because they only create a window hidden behind a newly focused window).

One-size-fits-all woes I guess.

I just wrote a "program" (ok, tiny utility) that behaves like you describe, but don't worry, it's for my personal use so you you won't have to deal with it :)

(i run it when I have an image in the clipboard and it shows an always-on-top window with that image. i can drag it around but it doesn't take focus. it's so on my single monitor setup (aka laptop on the couch) I can take a snapshot of something and then easily reference it in a maximized/semi-fullscreen application). I honestly mostly wrote it to see how fiddly winapi stuff from rust is but I actually end up using it a bunch)

I see where Wayland is coming from but I've come around to preferring the chaos of every app getting to do whatever it wants over hoping that various compositors are willing to support some obscure special case some app or other might want. Like, it sucks if apps are misbehaving but it sucks more if you can't reasonably fix an app to behave like you want it at all.

They should probably put more than three lines of code in there?

Yeah, I think that extra layer of revision identity is giving my intuition trouble, like it's obvious it needs to be there but the consequences are still percolating through my head.

The impression I get from all the jj writeups is that the devs said "rebases are really cool, we should move heaven and earth to make them even cooler".

Wikipedia has some background on the spelling: https://en.wikipedia.org/wiki/Jujutsu#Etymology

> Jujutsu is derived using the Hepburn romanization system. Before the first half of the 20th century, however, jiu-jitsu and ju-jitsu were preferred,

I'm sure if I did the proper time investment I would enjoy jj. I've heard basically only good things about it in casual conversation. So far, my experience has been that I tried it, immediately got really annoyed that it automatically adds every untracked file that's not gitignored to the current commit, and was advised that I might want to stay with git if that's a problem.

That said, I struggle a bit with learning version control systems (that aren't git, like, I never really wrapped my head around svn or darcs or anything until they invented git). Seems like everybody just wants to write about the cool new commands they can run now instead of conveying how the data model works, or what mental model it wants to encourage. I had the same issue trying to get into pijul a while back, couldn't understand how to conceptualize the current state of a branch if I couldn't point at a commit in a tree and say "that's the branch, right there".

"In other words, I actually understand git, so I don't really need Jujutsu." sounds like jj is for people who don't understand git. That's naturally a contentious statement. It implies that jj doesn't offer anything to experts, which seems easy to contradict given how many people with git expertise will talk about getting value from jj. At worst, it could be taken as a bad faith kinda put-down, like, suggesting at jj users are worse at their job than people who make do with git. I think it's totally fair to take push back against how that was worded.

That's a really neat idea, damn.

Isn't the largest company most likely to have the DNS resolver closest to me?

Are you describing banning gay marriage as an "ideal" here or is there more controversy I didn't hear about?

If I could pay Mozilla to not do specific things, it'd be pretty tempting

Many people like talking about what they do for work, or their hobbies.

At my last job, a lot of our web services also benefited immensely from in-process caches and batching (to be fair, some of them were the cache for downstream services), and their scaling requirements pretty much dominated our budget.

I can totally see how the cgi-bin process-per-request model is viable in a lot of places, but when it isn't, the difference can be vast. I don't think we'd have benefited from the easier concurrency either, but that's probably just because it was all golang to begin with.

structopt/Clap's derive magic is one of the first things I miss when I go to write some more-or-less trivial program in a non-Rust language these days. Being able to define all the data for a command line argument in one place (how/where to store it, what the type/valid input is, the association between the name and a variable/field, the documentation for --help...) seems like table stakes but afaict almost every other argument parsing library makes me repeat myself to the point where it takes all the joy out of writing a simple program.

(Python's docopt is also amazing, fwiw)

Can you say more about what the consensus is that this is going against?

Sorry OP I was so mesmerized by the cute mouse interaction in the logo that I didn't yet get around to checking out what this site is about.