Jean Boussier
@byroot.bsky.social
Rails core, Ruby committer, Senior Principal Engineer at Intercom.
Looks like someone testing some sort of repo migration script.
I don’t think it’s shady, just a bit irresponsible
I don’t think it’s shady, just a bit irresponsible
January 16, 2026 at 9:37 AM
Looks like someone testing some sort of repo migration script.
I don’t think it’s shady, just a bit irresponsible
I don’t think it’s shady, just a bit irresponsible
I suppose they could, but I do expect to be able to ping someone from about any public place on GitHub. I often do and it's very useful.
January 15, 2026 at 11:40 PM
I suppose they could, but I do expect to be able to ping someone from about any public place on GitHub. I often do and it's very useful.
Got it too. Insta blocked the account.
Definitely an annoying GitHub behavior, but at the same time I'm not sure what they could change.
Definitely an annoying GitHub behavior, but at the same time I'm not sure what they could change.
January 15, 2026 at 5:52 PM
Got it too. Insta blocked the account.
Definitely an annoying GitHub behavior, but at the same time I'm not sure what they could change.
Definitely an annoying GitHub behavior, but at the same time I'm not sure what they could change.
Docker caching is so arcane and brittle that in the past I basically gave up and did my own cache keys by pushing/pulling intermediate layers at predictable locations.
e.g. REGISTRY/intermediates:bundler-%{SHA1(Gemfile, Gemfile.lock)}
Worked super well.
e.g. REGISTRY/intermediates:bundler-%{SHA1(Gemfile, Gemfile.lock)}
Worked super well.
https://registry.io/intermediates:bundler-%{SHA1(Gemfile
January 6, 2026 at 11:18 PM
Docker caching is so arcane and brittle that in the past I basically gave up and did my own cache keys by pushing/pulling intermediate layers at predictable locations.
e.g. REGISTRY/intermediates:bundler-%{SHA1(Gemfile, Gemfile.lock)}
Worked super well.
e.g. REGISTRY/intermediates:bundler-%{SHA1(Gemfile, Gemfile.lock)}
Worked super well.
Of course, but I was working on bootsnap recently, and would really love to make things cleaner.
I think it may be time to try to integrate bootsnap in bundler itself.
I think it may be time to try to integrate bootsnap in bundler itself.
January 4, 2026 at 11:22 AM
Of course, but I was working on bootsnap recently, and would really love to make things cleaner.
I think it may be time to try to integrate bootsnap in bundler itself.
I think it may be time to try to integrate bootsnap in bundler itself.
> it doesn't address that code expects that $LOAD_PATH only contains Strings.
Rereading the ticket, I'm not sure this is really a big deal. Is that sort of code even common?
Also you'd only be exposed to that if upgrading to newer bundler so there would be plenty of time to adapt?
Rereading the ticket, I'm not sure this is really a big deal. Is that sort of code even common?
Also you'd only be exposed to that if upgrading to newer bundler so there would be plenty of time to adapt?
January 4, 2026 at 11:21 AM
> it doesn't address that code expects that $LOAD_PATH only contains Strings.
Rereading the ticket, I'm not sure this is really a big deal. Is that sort of code even common?
Also you'd only be exposed to that if upgrading to newer bundler so there would be plenty of time to adapt?
Rereading the ticket, I'm not sure this is really a big deal. Is that sort of code even common?
Also you'd only be exposed to that if upgrading to newer bundler so there would be plenty of time to adapt?
I think we really should work on getting rid of the require overrides.
I was rereading bugs.ruby-lang.org/issues/16848 just yesterday, I think we should revive that feature request.
Happy to brainstorm it with you if you are interested.
I was rereading bugs.ruby-lang.org/issues/16848 just yesterday, I think we should revive that feature request.
Happy to brainstorm it with you if you are interested.
Feature #16848: Allow callables in $LOAD_PATH - Ruby - Ruby Issue Tracking System
Redmine
bugs.ruby-lang.org
January 4, 2026 at 10:26 AM
I think we really should work on getting rid of the require overrides.
I was rereading bugs.ruby-lang.org/issues/16848 just yesterday, I think we should revive that feature request.
Happy to brainstorm it with you if you are interested.
I was rereading bugs.ruby-lang.org/issues/16848 just yesterday, I think we should revive that feature request.
Happy to brainstorm it with you if you are interested.
Reposted by Jean Boussier
Finally, www.ruby-lang.org/en/ has a new design.
December 20, 2025 at 8:07 AM
Finally, www.ruby-lang.org/en/ has a new design.
Reposted by Jean Boussier
We were very proud to present @marcoroth.dev with the Rails Luminary Award 2025.
And yes, I was on a secret mission to Zurich 😀.
rubyonrails.org/2025/12/17/m...
And yes, I was on a secret mission to Zurich 😀.
rubyonrails.org/2025/12/17/m...
Congrats Marco Roth: 2025 Rails Luminary
We are stoked to share that the Rails Core team has announced Marco Roth as the 2025 Rails Luminary.
rubyonrails.org
December 17, 2025 at 11:10 PM
We were very proud to present @marcoroth.dev with the Rails Luminary Award 2025.
And yes, I was on a secret mission to Zurich 😀.
rubyonrails.org/2025/12/17/m...
And yes, I was on a secret mission to Zurich 😀.
rubyonrails.org/2025/12/17/m...
Reposted by Jean Boussier
I'm really happy to see @marcoroth.dev receive the 2025 Rails Luminary Award! 🎉
He’s done so much for the Rails ecosystem and the Ruby community.
Huge congrats, Marco! 🙌
And it's great to have @fxn.bsky.social and @amandabrooke.bsky.social around.
#rails #RubyOnRails #ReActionView #herb
He’s done so much for the Rails ecosystem and the Ruby community.
Huge congrats, Marco! 🙌
And it's great to have @fxn.bsky.social and @amandabrooke.bsky.social around.
#rails #RubyOnRails #ReActionView #herb
December 17, 2025 at 7:55 PM
I'm really happy to see @marcoroth.dev receive the 2025 Rails Luminary Award! 🎉
He’s done so much for the Rails ecosystem and the Ruby community.
Huge congrats, Marco! 🙌
And it's great to have @fxn.bsky.social and @amandabrooke.bsky.social around.
#rails #RubyOnRails #ReActionView #herb
He’s done so much for the Rails ecosystem and the Ruby community.
Huge congrats, Marco! 🙌
And it's great to have @fxn.bsky.social and @amandabrooke.bsky.social around.
#rails #RubyOnRails #ReActionView #herb
No, the spec state the headers must be normalized (which makes sense for an interface).
Servers would be free to expose the original headers in another way, but that would be outside the spec, and I don't know any server doing that.
Servers would be free to expose the original headers in another way, but that would be outside the spec, and I don't know any server doing that.
December 8, 2025 at 7:35 PM
No, the spec state the headers must be normalized (which makes sense for an interface).
Servers would be free to expose the original headers in another way, but that would be outside the spec, and I don't know any server doing that.
Servers would be free to expose the original headers in another way, but that would be outside the spec, and I don't know any server doing that.
Reposted by Jean Boussier
Read on Slack:
"And yeah schema based multi tenancy made me question my career choices"
😄
"And yeah schema based multi tenancy made me question my career choices"
😄
November 25, 2025 at 11:48 AM
Read on Slack:
"And yeah schema based multi tenancy made me question my career choices"
😄
"And yeah schema based multi tenancy made me question my career choices"
😄
Nah, it's just that extending an object means creating a singleton class. If it's just for a single object it's fine, but you you are doing this for lots of objects, it means the class will be different every time and that trashes the VM caches.
November 24, 2025 at 9:23 PM
Nah, it's just that extending an object means creating a singleton class. If it's just for a single object it's fine, but you you are doing this for lots of objects, it means the class will be different every time and that trashes the VM caches.
99.999% of the time it's best not to use it though.
November 24, 2025 at 6:56 PM
99.999% of the time it's best not to use it though.
Alright, you got a point :)
November 24, 2025 at 1:55 PM
Alright, you got a point :)
Not just conceptually!
November 24, 2025 at 1:40 PM
Not just conceptually!
I'm not sure what the context is in your case.
It did happen that I declined discussing things further until some prototype was published.
It's super easy to talk over each others head with prose. With code, there's no misunderstanding, it makes it clear what the goal is.
But to each their own.
It did happen that I declined discussing things further until some prototype was published.
It's super easy to talk over each others head with prose. With code, there's no misunderstanding, it makes it clear what the goal is.
But to each their own.
November 21, 2025 at 8:09 PM
I'm not sure what the context is in your case.
It did happen that I declined discussing things further until some prototype was published.
It's super easy to talk over each others head with prose. With code, there's no misunderstanding, it makes it clear what the goal is.
But to each their own.
It did happen that I declined discussing things further until some prototype was published.
It's super easy to talk over each others head with prose. With code, there's no misunderstanding, it makes it clear what the goal is.
But to each their own.
So I took half an hour to open a prototype PR and then it was much more clear what I intended to do: github.com/puma/puma/pu...
Implement `env["puma.mark_as_io_bound"]` by byroot · Pull Request #3816 · puma/puma
Fix: #3777
Workers can now be marked as "IO bound". This state last until the end of the current request.
At the end of the request, the pool decide whether the "IO bound" threa...
github.com
November 21, 2025 at 2:34 PM
So I took half an hour to open a prototype PR and then it was much more clear what I intended to do: github.com/puma/puma/pu...
Even for bigger changes, sometime a quick prototype PR help convey the intention much better than a long discussion.
Case in point, I opened github.com/puma/puma/is... to test the waters, but kept answering the same questions, clearly it wasn't clear to everyone what I had in mind.
Case in point, I opened github.com/puma/puma/is... to test the waters, but kept answering the same questions, clearly it wasn't clear to everyone what I had in mind.
Feature: Add API to "remove" current thread from the pool · Issue #3777 · puma/puma
Is your feature request related to a problem? Please describe. A common problem in applications is how to handle uneven mix of IO-heavy and CPU-heavy requests. It's not rare for application that ar...
github.com
November 21, 2025 at 2:34 PM
Even for bigger changes, sometime a quick prototype PR help convey the intention much better than a long discussion.
Case in point, I opened github.com/puma/puma/is... to test the waters, but kept answering the same questions, clearly it wasn't clear to everyone what I had in mind.
Case in point, I opened github.com/puma/puma/is... to test the waters, but kept answering the same questions, clearly it wasn't clear to everyone what I had in mind.
That's not actionable data though.
November 19, 2025 at 10:02 PM
That's not actionable data though.
All I can think of is: for the love of god, gimme the raw data!
I’m sure there are API that are just begging to be optimized.
I’m sure there are API that are just begging to be optimized.
November 19, 2025 at 8:50 PM
All I can think of is: for the love of god, gimme the raw data!
I’m sure there are API that are just begging to be optimized.
I’m sure there are API that are just begging to be optimized.
"Our data backs up other findings that Ruby applications are generally less I/O-heavy, spending as much or more time on CPU as they do waiting on other services or database requests."
www.datadoghq.com/blog/ruby-pe...
www.datadoghq.com/blog/ruby-pe...
Optimizing Ruby performance: Observations from thousands of real-world services | Datadog
Learn about trends in Ruby development and opportunities for improving performance that many organizations are leaving on the table.
www.datadoghq.com
November 19, 2025 at 5:56 PM
"Our data backs up other findings that Ruby applications are generally less I/O-heavy, spending as much or more time on CPU as they do waiting on other services or database requests."
www.datadoghq.com/blog/ruby-pe...
www.datadoghq.com/blog/ruby-pe...
Ruby and Rails are very similar in their versioning scheme. The major is used for marketing, the minor is equivalent to a major in SemVer term, and the patch is what SemVer people expect.
November 17, 2025 at 11:25 AM
Ruby and Rails are very similar in their versioning scheme. The major is used for marketing, the minor is equivalent to a major in SemVer term, and the patch is what SemVer people expect.
That’s more or less how we do it it Rails. There’s deprecation message mention the release that will remove the API.
November 17, 2025 at 8:37 AM
That’s more or less how we do it it Rails. There’s deprecation message mention the release that will remove the API.
Ruby is in a trolling mood today 😂
November 14, 2025 at 6:56 PM
Ruby is in a trolling mood today 😂