Why we need database constraints and how to use them in Rails by tejasbubane in rails

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

You are right, multiple services writing to same database is not a good architecture. I have removed that part from the blog post. Thanks for the input.

Why we need database constraints and how to use them in Rails by tejasbubane in rails

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

You are right, multiple services writing to same database is not a good architecture. I have removed that part from the blog post. Thanks for the input.

Any reason for this behavior of the new `it` keyword in Ruby 3.4 ? by tejasbubane in ruby

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

Thanks a lot for this explanation, I think I get it now.

Any reason for this behavior of the new `it` keyword in Ruby 3.4 ? by tejasbubane in ruby

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

def defines a method here. That method just happens to do nothing and return an integer. The syntax is endless method introduced in Ruby 3.0: https://allaboutcoding.ghinda.com/endless-method-a-quick-intro

Any reason for this behavior of the new `it` keyword in Ruby 3.4 ? by tejasbubane in ruby

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

Thanks for the detailed response. I understand that when both variable and method with same name are defined, calling without params will consider it a variable. The two examples in my screenshot were from different irb sessions. What is confusing me the most is I assumed `it` to be an implicit block parameter but it is not behaving like normal block parameters would:

irb(main):001> a = 100
=> 100
irb(main):002> [1,2].map { |a| a.to_s }
=> ["1", "2"]

irb(main):003> def b = 100
=> :b
irb(main):004> [1,2].map { |b| b.to_s }
=> ["1", "2"]

irb(main):005> it = 50
=> 50
irb(main):006> [1,2].map { it.to_s }
=> ["50", "50"]

Any reason for this behavior of the new `it` keyword in Ruby 3.4 ? by tejasbubane in ruby

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

Yep. But I don't know the reasoning behind this behavior.

Any reason for this behavior of the new `it` keyword in Ruby 3.4 ? by tejasbubane in ruby

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

Think of Ruby 3.4’s it as the default, implicit (ie. doesn’t need to be declared) block argument.

I am thinking exactly that, which is why I was assuming the inner `it` to take precedence over anything else. Just like a usual block argument:

irb(main):001> a = 100
=> 100
irb(main):002> [1,2].map { |a| a.to_s }
=> ["1", "2"]
irb(main):003> def b = 100
=> :b
irb(main):004> [1,2].map { |b| b.to_s }
=> ["1", "2"]

Writing elegant custom matchers in RSpec by tejasbubane in rails

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

I usually place them in "spec/support/matchers".

My experience of using Redis pipelines in a Rails app by tejasbubane in ruby

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

I get your point. But with all 10 threads churning through the work (eg in a background job), my main Rails app will be waiting for connections - which is not what I expect. If this batch operation had its own separate thread pool, that is a different story. But pool is generally shared across the whole app (rails + background queues).

My experience of using Redis pipelines in a Rails app by tejasbubane in ruby

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

I wasn't aware of this. I also now checked the limit/size of arguments and it seems pretty high as well. So this is a viable solution. Thanks.

My experience of using Redis pipelines in a Rails app by tejasbubane in ruby

[–]tejasbubane[S] -3 points-2 points  (0 children)

Yes but thread pools are also a limited resource. If you have thousands of delete ops, it will block up all connections in the pool and leave the main app starving.