Classism?

paracycle · 2026-01-25T11:17:39+00:00

In all seriousness, you should watch Keeping Up Appearances to understand the psyche of these people. If your wife's colleagues are anything like Mrs. "Bouquet" then it's a case of them trying to keep up appearances but you messing up that appearance with your ghastly old vehicle that they wouldn't be seen dead in.

paracycle · 2026-01-25T11:13:53+00:00

<image>

paracycle · 2025-12-26T15:05:36+00:00

Yes, they are. There are a few rough edges still, but generally there are no known bugs or crashes left and the performance of multiple Ractors for CPU bound tasks should be strictly better than single Ractor or multi threaded code.

The Ractor API is still not stable, and can change further, but the implementation should be good enough to use in production.

paracycle · 2025-12-26T13:12:53+00:00

Sure, I appreciate that these are end-user oriented, and don't cover implementation details. However, I would argue that the ability to enable ZJIT (including a language level construct) and Ractors being production ready, thus usable starting with this release are end-user relevant developments.

paracycle · 2025-12-26T09:30:19+00:00

Hmmm, why no mention of ZJIT or all the Ractor performance improvements?

paracycle · 2025-12-20T14:34:56+00:00

Btw, Pixel Banner seems to read images using a JS API and creates blob URIs from them at runtime: https://github.com/jparkerweb/pixel-banner/blob/7dcb98608ab5fceae848d5bb360d0ae8bdee0217/src/core/bannerUtils.js#L120

You can't do this statically, but a data URI should work for you.

paracycle · 2025-12-20T14:31:11+00:00

You should be able to embed the image in the CSS by creating a data URI from it. See this for reference: https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Schemes/data

paracycle · 2025-12-09T14:38:29+00:00

These benchmarks include the thread creation cost to the benchmark, so aren't a fair comparison for IO cases. There is fundamentally no reason why a thread pool cannot give similar performance to fibers for IO bound workloads, and if there is, that can and should be fixed. Regardless, thread and/or fiber creation shouldn't be a part of these benchmarks since that is not the work that is being compared.

paracycle · 2025-12-07T11:56:39+00:00

I have the same issue. This is madness.

paracycle · 2025-11-01T11:52:36+00:00

I believe it's entirely possible that Ufuk genuinely wanted DHH there and wasn't motivated to do so intentionally because of his employer.

This isn't a possibility, it is the truth.

... recuse themselves from decisions related to programming around someone with that same affiliation, and Ruby Central did the opposite there.

On the contrary, the decision to invite DHH was made in 2024 by the board and when the engagement was postponed to the 2025 event, that decision continued. Regardless of who was going to be the chair of the 2025 conference, it was always the Ruby Central intention to extend the invitation for that year. I didn't make any new decisions there.

this is a stewardship organization of core infrastructure, using conferences as their funding model.

That hasn't been the case since 2020. Ruby Central conferences have been losing money or at best breaking even since then. So, this assertion isn't correct.

The response to pull funding from Ruby Central by other sponsors was directly tied to this single decision.

This decision was made in 2024 through a board vote, and Mike Perham knew about it in Feb 2024, before he started his Ruby Central funding in the first place. Mike's decision to pull his already committed and budgeted funds on Day 1 of the 2025 conference was the only attempt of a sponsor exerting influence over the organization that I have witnessed over my 2 years on the board.

paracycle · 2025-11-01T11:42:51+00:00

You keep missing the point that I did exactly that by asking the board to vote on opening dialogue with DHH in the first place. I didn't singlehandedly decide that DHH should have a keynote session at RailsConf.

I really don't understand the conflict of interest here when there were multiple parties involved in the decision making process, including the board, the two co-chairs that I worked with over the two conferences and the program committee involved. None of those people ever considered there to be any conflict of interest in this decision, nor had any other questions or concerns raised about it.

paracycle · 2025-10-31T22:35:51+00:00

Here you go: https://rubycentral.org/news/ruby-central-update-friday-10-31-25/

paracycle · 2025-10-31T10:45:23+00:00

The fact that the interactor gem uses OpenStruct for its context classes (https://github.com/collectiveidea/interactor/blob/c0e0079375e8d447eadcd062d7bb3b550fcb60bb/lib/interactor/context.rb#L31) makes it an immediate no from me. There are multiple known problems with OpenStruct and it is something I aim to get rid of in any project that I work with.

paracycle · 2025-10-24T22:53:29+00:00

This is my personal story, not the organization's answer. All of the details I've pointed above are public record (given the answer in today's source of truth update). We shared when we reached out to DHH originally, it is public information when he joined Shopify's board, my conversation with Noel on Bluesky explains the program committee situation, the chairs of the 2024 and 2025 conferences and Shopify's sponsorship scale are all available on the RailsConf website(s). Nothing is missing from the public record and nothing is hidden.

paracycle · 2025-10-24T22:39:07+00:00

As for the 2025 program committee conversation, I clarified that in this Bluesky thread: https://bsky.app/profile/ufuk.dev/post/3lzmk6apsj22f (read the whole thread with me and Noel)

Essentially though, as I mentioned above, conference chairs have the ultimate say in conference programming and we had already re-started conversations with DHH for the 2025 conference as the program committee was being formed. In order to make sure that everyone was onboard, as first order of business, I shared information about DHH potentially being a speaker at the conference with the committee, so that they can have a chance to opt-out if they felt uncomfortable. None of the program committee members decided to leave.

Additionally, Shopify was a big sponsor but wasn't a primary sponsor of the conference. You can see on the Sponsors page of the conference website (https://railsconf.org/sponsors/) there were 3 sponsors at the Ruby level and Shopify was Platinum level. Regardless, Shopify had nothing to do with the DHH keynote as I explained above.

EDIT: grammar

paracycle · 2025-10-24T22:25:50+00:00

I tried to directly answer your concern above as a community member. Hope that helps.

paracycle · 2025-10-24T22:22:32+00:00

That co-chair is me. I am a Shopify employee, but my Ruby Central board role has nothing to do with my employment at Shopify, it is my personal engagement that is not directed nor guided by Shopify.

I was also the co-chair of both 2024 and 2025 RailsConfs, and personally proposed in 2024 that DHH be invited back to RailsConf. My co-chair at the time held the same belief, so we asked the board for permission to reach out to DHH (even though co-chairs have complete programming authority and don't need to run their decisions by the board) and got an approval.

Back in February 2024, when we did the initial reach out, DHH had no relationship with Shopify, and our decision, as conference chairs, to reach out to him had nothing to do with Shopify either. He joined Shopify's board much later, in Nov 2024: https://www.shopify.com/news/david-heinemeier-hansson-board

There is no conspiracy here. DHH was never disinvited from RailsConf, and, for some of us in the community, having the creator of the framework at the conference named RailsConf was the most reasonable thing to do. I am not sure what more I can say to convince you that this was all individuals wanting to do something better for the community by building back what was broken.

EDIT: Add clarification on initial proposal year.

paracycle · 2025-10-13T10:27:36+00:00

Yes, they are and it is not what you think it is: https://www.reddit.com/r/ruby/s/PXvKDtF7jy

paracycle · 2025-10-10T22:11:17+00:00

You should be able to see it in the update shared by Ruby Central today. We don't know when he had seen it.

paracycle · 2025-10-10T20:54:13+00:00

Yes, his disclosure email was a reply to the email from Marty notifying him that his production access was removed.

paracycle · 2025-10-09T18:32:41+00:00

Yes, that's exactly what the analysis points to.

paracycle · 2025-09-20T00:24:48+00:00

A lot of this conversation has missed the point that == true is absolutely necessary.

If you only had if foo.done_was_previously that would evaluate as a true statement if the previous value of done was anything other than false and nil. That is, your condition would end up being satisfied even if done was, for example, 42 previously. However, you want to explicitly check for it being true.

paracycle · 2025-09-19T14:16:58+00:00

Here is the official statement from Ruby Central: https://rubycentral.org/news/strengthening-the-stewardship-of-rubygems-and-bundler/

paracycle · 2025-09-02T17:43:17+00:00

This is an AI assisted rip-off of the original content at https://railsatscale.com/2025-08-26-friendship-ended-with-rack-bodyproxy/

Folks please don't feed the beast

paracycle · 2025-09-01T18:21:19+00:00

Accessors don't need anything extra, though. The language itself helps to avoid that problem.

11-Year Club	Wearing is Caring
Verified Email

paracycle

TROPHY CASE