It's an interesting trick, but for a setter method you really need to use `def cloaking=(value)` instead of overloading the same method. It would help to give a more realistic example for where this technique can be useful.
Had a difficult time trying to think of a good example, and settled on "legacy config code whose contract you absolutely can't change for <reasons>" + "spaceships."
Not totally following this one. If the contract of your methods needs to differentiate an actually supplied "nil" from "nothing was supplied", how does `defined?` accomplish that? For ex, using it would break the intended contract here:
irb(main):020\* def cloaking(value = nil)
irb(main):021\* if defined?(value)
irb(main):022\* @value = value
irb(main):023\* else
irb(main):024\* @value
irb(main):025\* end
irb(main):026> end
=> :cloaking
irb(main):027> cloaking("on")
=> "on"
irb(main):028> cloaking()
=> nil
irb(main):029> cloaking("on")
=> "on"
irb(main):030> cloaking
=> nil
calling cloaking with no argument clears the value this method is intended to read. could `defined?` be used to accomplish this in some way I didn't demonstrate here?
Personally I prefer the longer variants, e. g. enable_colours
and disable_colours (without trailing (); if people prefer
US spelling the method names could be enable_colors etc.. it
is really the very same point anyway). I do, however had,
also sometimes use a more generic top-level entry point such
as enable. I use that for my pseudo-shell replacement for
bash, written in ruby too. For instance:
enable :windows_configuration
enable :colours
enable :systemd # and so on and so forth.
I mostly do this so I have an easier time remembering things;
and finding a simple, ideally as simple as possible, entry
point.
Of course it is not exactly the same as the rails-idiom shown
here, since I'd also have to use:
colours :green
colours :disable
colours false
But I am also fine with set_colours :false. But in general I
tend to prefer disable_colours in this case.
Personally, since I know my brain is rather weak, I try to not
use "cloaked" methods and just use oldschool setters and
getters, where I treat set_foobar to be the same as foobar =.
foobar= is a bit more elegant, but I also like set_xyz in general.
Oddly enough I don't really use get_xyz; but I, to my shame, must
admit that I like this:
def return_base_directory
Most will omit "return_", but I kind of like stupid code where I
don't have to think. In particular in bigger projects.
I don't really see a need for overloading methods though. I dislike
having too many instance variables however had; I noticed that when
I have like more than 10 @ variables, I often find it easier to just
group them into a Hash instead, with Symbols as key. So for instance:
@internal_hash[:use_colours] = false
It's not that elegant compared to:
@use_colours = false
but I found a Hash to just be a lot more convenient
to use here. And pp hash is super-userful. (We can
easily get all instance variables programmatically,
of course, but I still find a Hash structure so much
more logical and convenient to use and read than many
different instance variables.)
In pracitce, those root CAs have already been removed in major browsers. If your server uses them, you would likely have needed to migrate to another root already.
The recent monetization strategy for Maven Central has been bizarre.
First it seemed like they want to encourage reducing usage (release sizes and file counts), which is fair. It would still be better focus on improving the default tooling to not producuce 10x checksum files with each artifact, and 6MB+ javadoc bundles that no-one reads, but that's a little beside the point.
Then they started requiring paid plans for _all_ publishers that are not purely community projects. Doesn't matter how open it is, if it's backed by a commercial company, they require a paid plan.
Now, in principle I don't mind paying for usage. But they promised self-serve signups before the limits are applied, which didn't happen - still no self-serve plans available. And the "contact us" pricing is too a large extent based on _popularity_ of the package. And not in a quantifiable way like "x GB downloaded", but rather "within the top 2% of usage" (by whatever hidden metric).
So if they lose half their publishers because they don't want to pay, it means I'll automatically be in a higher bracket next year, even if nothing changed on my side?
And the pricing ends up in a couple thousand $ per year, for something that would have been single-digit dollars when self-hosting on S3. When their main value add over that is that Maven Central is automatically present in user config.
> The recent monetization strategy for Maven Central has been bizarre.
Well, someone gotta pay the bills and it is not surprising given that they began to squeeze Sonatype Nexus operators for money a few years ago.
The core problem is that sooooo much of the core infrastructure we assume as "given" is in fact not owned and operated by a non-profit NGO (such as e.g. Codeberg is) but by a commercial company.
Sonatype operates Maven Central, NuGet, Github and NPM are run (into the ground) by Microsoft, Gitlab is funded by its commercial arm and, assumedly, a lot of venture capital that eventually wants to be returned to the investors, Sourceforge always was infamous for how they monetized (while the majority of the actual hosting cost was borne by universities LOL). The only major artifact repository I'm aware of that is not backed by either big corporate or NGOs and not tied to some Linux distribution is PHP Composer's Packagist that has a commercial arm, but no venture capital.
And in the end, the real issue at the root is that internet traffic, especially egress traffic, still is absurdly expensive, and the behavior of people like Sam Altman that sent RAM, SSD and even HDD prices through the roof is making the situation even worse.
So, so much negative side effects have been caused by just this one human. Sam Altman is nothing short of Thomas Midgley Jr.
>And in the end, the real issue at the root is that internet traffic, especially egress traffic, still is absurdly expensive, and the behavior of people like Sam Altman that sent RAM, SSD and even HDD prices through the roof is making the situation even worse.
The core problem is that dependencies don't really scale. Find a security issue in one dependency? It has to be updated. All the projects which depended on it need to be updated. Turtles all the way down. AI worsened this further by accelerating the churn with vulnerability scanning. Naturally, they focus on the core projects like apache-commons which fans out to basically everything in the Java universe. Which means maven central becomes overloaded and now needs to make emergency changes to stay solvent.
long-time java dev and did a portion of my startup on dial-up. they've been hostile to any attempt to optimize for bandwidth for a very long time - i had elaborate hoops i jumped through to implement caching that should have been baked in to the tooling
I've been a user of the Java/Maven ecosystem for decades. Maven has had local caching of artifacts for as long as I can remember, and there are several ways to set up a private repository mirror for caching and reproducibility.
The interests of the Maven project (i.e. the Maven community), Sonatype and other actors in the space are not necessarily aligned.
But I do wonder where you had to jump through hoops? A basic Squid caching proxy should be enough at least for a pure pull-through like Maven Central. Once you have to publish stuff, okay, that is messy, you won't get anywhere with just Squid there.
> I would assume they primarily serve static files that can be on a cdn
And someone gotta pay that CDN bill too.
On top of that come all the requests from CI pipelines that don't have a repository proxy at all or have it misconfigured, the AI scrapers and other bots, or DDoS skiddies wanting to take responsibility for taking down a major hoster.
I don't know what Cloudflare's economics are like, but R2 egress is free. You pay for storage and $0.36/million for cache misses, which should be a fairly small percentage.
If I had to build a public artifact repository today, that's what I would use. Apparently Maven Central is built on S3 and Fastly. We don't know the terms, but I'm guessing that is more expensive.
Unless you truly self-host, get your own ASN and do your own peering, you most likely pay egress. But that's not to say this is the only way to operate, if you manage your own ASN and peering, you stop paying per TB transferred and start paying for available bandwidth instead.
Given the technical chops, it wouldn't be impossible to actually run a FOSS non-profit for hosting FOSS packages and libraries.
"Now, in principle I don't mind paying for usage. But they promised self-serve signups before the limits are applied, which didn't happen - still no self-serve plans available. And the "contact us" pricing is too a large extent based on _popularity_ of the package. And not in a quantifiable way like "x GB downloaded", but rather "within the top 2% of usage" (by whatever hidden metric)."
-> This too is also factually incorrect. Self service rolled out on 10/1 along side the new updated limits that had a -30 day- grace period reset for everyone. So minimally you had 30 days before anything would be impacted...we are still at day 19 so no one has been impacted at all yet. The actual grace periods don't start until you go over the monthly limits so practically speaking it would take a few months before most things would have any impact.
"Then they started requiring paid plans for _all_ publishers that are not purely community projects. Doesn't matter how open it is, if it's backed by a commercial company, they require a paid plan."
This is factually incorrect and has been documented and discussed many times. The issue at hand is if something is open source vs "open source" but is really a free to paid go to market motion. This includes "open source" sdks that are only really used to build products against a paid commercial service.
We spend great time and care assessing each situation and discussing the results with the companies engaged with us to reach a fair conclusion.
If you think we got something wrong here, all you have to do is reach out and we are happy to walk you through what we see and drive to resolution.
The readme has a lot of words but still does not clearly explain what this does or what you'd use it for.
The best I can gather is that this captures telemetry while you're running some computationally-expensive job, and checks that the resource usage roughly matches what it's supposed to be. But what does "Tamper-evident" mean? I assume you sign with your own private key? What exactly prevents the data from being faked?
> "A run of committed code, on attested hardware at time T, reading a model with hash m and a dataset with hash d, produced score S.” If d is a public benchmark, they also confirm it is the real benchmark, without you exposing it. The score is also cross-checked by the compute-cost certificate, which confirms the evaluation consumed the compute a real forward pass over the data requires.
They should really put that front and center. Still not a complete enough description, but something at least.
It didn't sound very convincing. It doesn't really prove anything other than the author signed the report. Unless the auditing is running from a secure enclave/core that the user has no access to, it can't do what is claimed on the tin.
There alternatives to a secure enclave like building in a risc0 VM that produces a mathematical proof of each computational step that is very expensive to generate and very cheap to verify. THAT is proof.
But this seems to just be collecting evidence and signing it?
This is exactly what it is, just slop. I do agree with the intent we need someway to verify and validate agentic coding output that doesn't rely on codereviews; but this project is just sloppy.
You can merge one by one, but if you're using squash and merge, you need a re-approval for each PR in the stack if you require reviews. This makes you lose out on arguably the biggest gain of stacked PRs.
The command line tooling (gh stack) helps to make things slightly less manual, but you still need to be very aware of how git rebase works, the tooling just helps automate it across multiple branches. For example, just running the "gh stack rebase" commands that the UI suggests won't work if your local branches are not in sync with the remote ones, and the tooling won't point that out to you.
I do find the stack UI quite nice. It's quite minimal compared to standalone PRs, but it's enough to show the relationship between them.
(My comments all assume you already have a good reason to stack PRs. This tooling just help to make the workflow easier, it does not give any new capabilities)
We're rolling out a series of bug fixes for the issues with squash merging.
There's an internal system we have called CPRMC (Create Pull Request Merge Commit) that is used to evaluate whether a PR is "ready" to merge. This covers everything from mergeability (checking for merge conflicts) to rule evaluations (ensuring that approvals match the potential commit that will be created by merge) and more.
This becomes particularly difficult when squash merging a stack of multiple PRs because we have to calculate a series of squashed commits, then associate those back to the rules/reviews. This is relatively easy for the first PR, but for the second PR onwards this gets more complicated because the ancestor commits are squashed and don't exist on the branch as-is. And I won't get into how much more complicated it gets for multi-parent situations lol.
It's something we need to fix and it's the top priority for the team. Our numbers show that 99% of stack merges go through successfully, but we need to get that much higher.
Thank you for being an early user in the preview and bearing with us while we work out these issues!
Can you make sure there is good API support for stacks?
We use a custom merge queue and we want it to be able to land multiple PRs from a stack at once as separate PRs. Last I checked you had to land a single PR, rebase the stack, land the next and so on. This is very expensive in CI time (and wall clock time), vs simply testing part or all of a stack in parallel then declaring those merged. In essence a robot needs the ability to say “squash merge these 3 stacked PRs”, after the queue does its thing.
Yes that was one of our top priorities. For one, there's a fully public API for all stack operations. So if you don't want to use the `gh stack` CLI, you can build your own: https://docs.github.com/en/rest/pulls/stacks
The legacy API was fully synchronous, and since stacks of multiple PRs can often take more than 10s (our global timeout), we had to move to async.
We've had some folks already use this to integrate stacks into their merge queues. The great part is you can land multiple PRs in one atomic operation, and then there's one push to main with all your commits from multiple PRs. So instead of having to rerun the build/deploy for each, it can trigger for the last commit that contains all of the changes.
We use GitHub's APIs. We did build a version before GitHub supported it, but it required using our credentials to push directly to the main branch. That wasn't acceptable to most of our customers, so we ended up not shipping it and waiting for GitHub support.
Using the GitHub APIs means you still preserve history and commit messages they way people expect (merges through the queue and direct merges behave the same), and it lets users guarantee that the only code our mergequeue merges is the code that was in the PR.
> There's an internal system we have called CPRMC (Create Pull Request Merge Commit) that is used to evaluate whether a PR is "ready" to merge. This covers everything from mergeability (checking for merge conflicts) to rule evaluations (ensuring that approvals match the potential commit that will be created by merge) and more.
By the way could there be a way to disable that when doing integrations externally? It seems to be quite costly (which makes sense), and the pull/ refs kinda bloat the reflist.
I’m sure that external integration is not exactly beloved internally but there’s really just a small handful of big annoyances which would make it so much nicer and more comfortable.
The feature is half baked. Just today I had to spend ~1hr untangling a mess it created. And there was no way to reorder the Stack without discarding PRs that already had many comments. I'm not an intentional an early adopter, someone on the team clicked the tooltip.
> This becomes particularly difficult when squash merging a stack of multiple PRs
I acknowledge that it is not trivial.
But this is 2026. Many people have solved this in in-house solutions. Every place I have worked at in the last 10 years had solutions in place. Some had wrinkles but it all worked in the end. Github sees itself as the leading provider of solutions in that space and has MSFT backing. Just saying that it's difficult is not good enough, quite frankly. People have been complaining about GH support for this for a long time.
> But this is 2026. Many people have solved this in in-house solutions. Every place I have worked at in the last 10 years had solutions in place. Some had wrinkles but it all worked in the end. Github sees itself as the leading provider of solutions in that space and has MSFT backing. Just saying that it's difficult is not good enough, quite frankly. People have been complaining about GH support for this for a long time.
But most of those solutions don't have the number of integrations and rules executions that GH has and that's where the challenge lies.
Again, it's by no means trivial. But in the last years we as an industry made private space travel viable, created self driving cars and made chatbots that can explain humor. Not being able to do stacked PRs in this day and age by the prime company in this area is just .. well you got the point.
> You can merge one by one, but if you're using squash and merge, you need a re-approval for each PR in the stack if you require reviews. This makes you lose out on arguably the biggest gain of stacked PRs.
I'm struggling to imagine what it offers at all if that doesn't work! Is it just a way of manually marking another MR as a dependency in the UI so that it shows up with a red X if the other one isn't merged yet?
Sure, I just think that "merging one by one" defeats the purpose of stacked PRs even if you don't need re-approval. You can already avoid re-approval today without needing re-approval if you're not rebasing (which is not what I'd expect you mean by "regular merging"; it sounds like you mean just having a merge commit) by just not clicking merge until the other PR merges first, and at that point. That's what I meant by it sounding like all this offers is an icon telling you whether that other one already merged or not.
Stacked PRs are so hard to implement for software not natively designed for them. Gitlab has been struggling with them too, despite 2.5 years since the MVP (https://gitlab.com/gitlab-org/cli/-/work_items/7473) . It doesn't help they want to do it without making any significant change outside the CLI, or that most developpers just... don't get it.
We just today ran into a bug where if the branch a stacked PR points to is deleted, it can just stay stuck in "merging" without any additional feedback. I directly looked at the GH status page, because who knows, maybe the PR subsystem has a partial outage again, but no, it was just a bug in the stacked PR feature.
It's been >4 years since I've been out of Facebook and now have to use Github, and to this day I miss phabricator and landing stacked changes. When I first left and had to work with github I hadn't realized that this, to me, very basic, workflow is _not_ a feature!
So many things on Github are now broken or utterly unusable, that this comment is not wrong. I mean even the code viewer/display is utterly broken and doesn't even perform standard text highlighting correctly. The folding marks often make no sense or are inconsistent. If one wants to see all forks of a repo, one has to go through "insights", I think few would suspect it to be located, and it doesn't show _all_ forks, according to the number displayed next to the fork button. The list of UI issues goes on and on. But then there are also the reliability issues, things being down every 2 weeks, or is it every week by now? Difficult to keep up with it really.
That's interesting, I get pushback when I suggest anything different and for devs under 30 I've had to remind them that git and github aren't the same thing. This is not to cast aspersions on them, just the state of things in the places I've worked.
Microsoft seems to be running the classic embrace, extend, extinguish playbook on github/git though. When it becomes impractical to join a team's workflow without github specific tooling then everyone will be forced to use gh.
If you thought git was complex, wait until you get your 5 deep stacked PR from that nice coworker! Jokes aside this is really an anti-feature. Now coworkers can blow off your PR for much longer.
I'd assume it's common knowledge that you cannot paginate using OFFSET + LIMIT unless you use ORDER BY on an unique set of columns, no matter what database you're using. The only exception is when the database provides an explicit order guarantee without the ORDER BY, such as the case with `preserve_insertion_order = true` here.
Yes, there is always a failure mode. But if do a search or have some result set, it is convenient to have paging work as close to expected as possible.
Say you are processing/shipping orders. You do the first page and then advance to page 2. The very next order may no longer be the next order that would have shown depending on how many orders came in. In fact if order are coming in fast it will be impossible to page through a search result. But if you incorporate the last I’d seen you will get something closer to what the user expects. Naive offset won’t give you this.
I'm not familiar with Outlook's resending, but the use case is supported if the sender uses DKIM. If the email is forwarded without changing any details, it can keep the DKIM signature. That allows the forwarded email to still pass DMARC.
Now if the sender used SPF + DMARC but not DKIM, this does not work, since the sender IP can't be verified with the forwarded email. In that case, the forwarder has to change the from address to prevent the email from failing DMARC and be rejected.
In practice, senders using SPF+DMARC but not DKIM should be quite rare, you see DKIM+DMARC much more often.
I have a long-standing email address that forwards to an email system that I run. The operator of the forwarder switched to using Microsoft's mail infrastructure some years ago and the quality of service of the forward has degraded dramatically ever since.
I've often seen messages resent by Microsoft's mail infrastructure with gratuitously broken DKIM signatures, generally due to changes to whitespace that are not anticipated by DKIM's message canonicalization.
I've also seen messages sent by my bank directly to the email system I administer that had broken DKIM signatures apparently due to some sort of antivirus software they had downstream of the DKIM signer.
I never understood the point of the anti-virus adding a message to _outgoing_ emails. Basically "I swear there is no virus in this email I'm sending you, trust me bro".
There are lots of free tools that automatically analyze the reports for you (you send it to them, instead of yourself).
But if you send all emails for your domain from one email server, you could just disable rua reporting. The reports are mainly useful to see whether you have some misconfigired email server somewhere that causes (or will cause) dropped emails. That can easily happen if you send some email from your own server, some via sendgrid, some via some marketing tool, and start to lose track of them. But for a personal email server, that's not common.
reply