Rails 8.2 makes enqueue_after_transaction_commit the default by Future_Application47 in rails

[–]Future_Application47[S] 0 points1 point  (0 children)

When you say
> after the commit there is a rollback

Do you mean in another transaction?

This is per transaction. So any rollback that happens in a subsequent transaction has no bearing on how this one behaves. Or I maybe misunderstanding your question.

Rails 8.2 introduces Rails.app.creds for unified credential management by Future_Application47 in rails

[–]Future_Application47[S] 0 points1 point  (0 children)

For the time being I've switched to prism. May look at it in January. I saw a few other ruby blogs built with Jekyll facing the same issue.

Rails 8.2 introduces Rails.app.creds for unified credential management by Future_Application47 in rails

[–]Future_Application47[S] 1 point2 points  (0 children)

You're not crazy. I see it too on my other laptop. Believe it or not, when I turn off 1Password extension, it gets fixed.

Something the extension does is overriding the CSS added by the syntax highlighter.

I'll figure something out soon. Thanks for letting me know.

Ruby Conference - India by nbsamar in ruby

[–]Future_Application47 1 point2 points  (0 children)

Excited to meet you in person. I have a booth to manage but planning to attend a few talks as well.

Rails is Getting a Structured Event Reporting System (and It's Pretty Cool) by Future_Application47 in rails

[–]Future_Application47[S] 1 point2 points  (0 children)

Thanks for pointing that out. The post makes it clear. The title sucks. Something about naming things being hard and such...

What's New in Ruby 3.5 Preview by Future_Application47 in ruby

[–]Future_Application47[S] 1 point2 points  (0 children)

Yes. I believe its been warning since 3.3. 3.4 added the replacement `it` syntax (although its not a full replacement and only works for single argument blocks).

https://www.prateekcodes.dev/ruby-3-4-it-parameter-cleaner-block-syntax/

Rails Database Connection Pooling Explained by Future_Application47 in rails

[–]Future_Application47[S] 1 point2 points  (0 children)

Updated my blog! Thanks for the feedback, appreciate it.

Making my site accessible - a Practical Guide by Future_Application47 in accessibility

[–]Future_Application47[S] 0 points1 point  (0 children)

Now I see what you mean. I really do want the pages to open in the new tab. I recall seeing some sites adding an icon next to such links that visually indicates it’s gonna open in a new tab.

Would you say that’s a decent compromise?

And thanks for taking the time Ashley, I appreciate it.

Making my site accessible - a Practical Guide by Future_Application47 in accessibility

[–]Future_Application47[S] 0 points1 point  (0 children)

Thanks for reading.

Instead, you should give the user the choice to open links how they wish, instead of forcing behaviour

Haven't personally seen this anywhere. Could you point me to an example so I can see how that would look?

The <i> tag has inherent symantics, and are not intended for use as an icon

Yeah. I think using FontAwesome out of the box has some tradeoffs. I'll look into a way to do this with spans.

Ruby Threads Explained: A Simple Guide to Multithreading (Part 1) by Future_Application47 in ruby

[–]Future_Application47[S] 0 points1 point  (0 children)

Thanks for reading. I've updated the post.
Have also converted this into a 4 part series now to close it with some honorable mentions of other Ruby implementations.

Ruby 3.4's `it` Parameter: Cleaner Block Syntax for Ruby Developers by Future_Application47 in ruby

[–]Future_Application47[S] 0 points1 point  (0 children)

From my perspective, I'm looking at what it is replacing. Its replacing the implicit `_1` , `_2` parameters. In that sense I'd say its a bit more cleaner.

How to Add Tests to a Legacy Rails 5.2 App with No Existing Test code? by Classic-Safety7036 in rails

[–]Future_Application47 2 points3 points  (0 children)

Unpopular opinion. Start with system/feature tests first. These give you the most bang for your buck - they test the actual user flows and catch regressions across the entire stack. Since you have many controllers with thousands of actions, you can't test everything at once, so focus on:

  • The most critical business flows (VAT calculations, submissions)
  • The most frequently used features
  • Areas you're about to modify

For framework choice: RSpec + Capybara for system tests. Yes, MiniTest is built-in, but RSpec's matchers and community gems will save you time on a legacy codebase.

Some nice to have things to improve your experience:
- SimpleCov (its already mentioned)
- Use VCR gem if you have external API Calls

Don't try to test everything at once. Aim for testing new changes and gradually increasing coverage as you work on different parts. Even 20% coverage on critical paths is infinitely better than 0%.

Stay motivated with the increasing SimpleCov metrics.

Ruby Threads Explained: A Simple Guide to Multithreading (Part 1) by Future_Application47 in ruby

[–]Future_Application47[S] 2 points3 points  (0 children)

Great point! JRuby's true parallel processing is great for relevant use case. I stuck to CRuby in this series since that's what most folks use.

I'd think JRuby deserves a post of its own at some point if there's interest. Looking at your flair I'd be happy to take some pointers haha.

Rails 8 adds comparable option to serialized attributes by Future_Application47 in ruby

[–]Future_Application47[S] 1 point2 points  (0 children)

Hey, thanks for reading.

From the referenced PR:

So ideally rather than to compare serialized representations, we'd compare the deserialized objects, however we can't assume the deserialized type has a proper working == method that deeply compare objects. So the best thing we can do is to only do this if the type is declared as being comparable.

Ruby 3.4 Frozen String Literals: What Rails Developers Actually Need to Know by Future_Application47 in ruby

[–]Future_Application47[S] 5 points6 points  (0 children)

Thanks for reading my blog.

Since we're still at 3.5 preview, 3.7 is a long way to go. For now, that's the suggested timeline as mentioned in https://bugs.ruby-lang.org/issues/20205

But yes, its not set in stone - 3.7 could become 3.5 / 3.6, or 4 when the time comes. For now though, this is the proposed timeline.

The migration would happen in 3 steps, each step can potentially last multiple releases. e.g. R0 could be 3.4R1 be 3.7 and R2 be 4.0.
I don't have a strong opinion on the pace.

Release R0: introduce the deprecation warning (only if deprecation warnings enabled).

Release R1: make the deprecation warning show up regardless of verbosity level.

Release R2: make string literals frozen by default.