ruby-science VS Sidekiq

So, bigger is worse, but how big is bad? At what number should you take action? Thoughtbot's Ruby Science book suggests a method is long or complex with a flog score above 10. It also posits that a class is long or complex with a flog score above 50.

Ruby Science - it's a free book by thoughtbot. It might be the most short term beneficial thing honestly. It just points out all of these various practical patterns you can immediate use to increase code quality.

I think you would appreciate Ruby Science. I love this book, it's extremely practical.

Well, if you're programming in Ruby, a great place to start is the Ruby Science book by ThoughtBot. It's a bottom-up approach to improving your code by identifying code smells and applying OO principles to fix them. Identifying smells in your own code will lead you to the OO principles that you need to learn to build your OO skills.

Read Ruby science to learn about code smells and good architecture.

It's a bit more advanced, but I like Ruby Science by thoughtbot.

Check out Ruby Science by Thoughtbot which I found useful at your stage.

Code smells. Ruby science is a good one for Ruby.

Currnetly reading ruby science. 200+ page guide on code smells and solutions.

This book is old but it's still very relevant https://github.com/thoughtbot/ruby-science. Also check out thoughtbot's blog and www.gorails.com

I like Solid Queue and the direction things are heading, but its hard to overlook the performance. A system that does tens to hundreds of thousands of jobs/s on Sidekiq + Redis, will now get bottlenecked by transactional performance with solid queue / PG - https://github.com/sidekiq/sidekiq/wiki/Active-Job#performan...

# copied from https://github.com/sidekiq/sidekiq/blob/main/Gemfile source "https://rubygems.org" gemspec gem "rake" RAILS_VERSION = "~> 8.0" gem "actionmailer", RAILS_VERSION gem "actionpack", RAILS_VERSION gem "activejob", RAILS_VERSION gem "activerecord", RAILS_VERSION gem "railties", RAILS_VERSION gem "redis-client" # gem "bumbler" # gem "debug" gem "sqlite3", "~> 2.2", platforms: :ruby gem "activerecord-jdbcsqlite3-adapter", platforms: :jruby gem "after_commit_everywhere", require: false gem "yard" gem "csv" gem "vernier" unless RUBY_VERSION < "3" gem "webrick" group :test do gem "maxitest" gem "simplecov" gem "debug" end group :development, :test do gem "standard", require: false end group :load_test do gem "toxiproxy" gem "ruby-prof" end

If you’re developing in Node, BullMQ has been rising in popularity as a go-to solution. For Rails applications, you can use ActiveJob with backends like Sidekiq for efficient background job processing.

Sidekiq is known for its fast and efficient processing using threads in Ruby, which allows it to handle many jobs concurrently.

I'm not sure I personally agree with this, and I'm not 100% sure the developer community at-large does either...

Let's take a few examples, which I've shared elsewhere in similar discussions:

- GitLab: Open Source or Open Core? Most would say Open Source, but (I assume) you would argue Open Core [0].

- Plausible: Open Source or Open Core? They say Open Source, but it's actually Open Core [1].

- Cal.com: Open Source or Open Core? They say Open Source, but once again, Open Core [2].

- Posthog: Open Source or Open Core? They say Open Source, still Open Core [3].

- Sidekiq: Open Source or Open Core? Once again: Open Core [4].

Yet, every dev I know would consider these projects Open Source. So there's a disconnect somewhere.

Under this mindset, very few open source startups are actually open source, yet everybody says they are?

I'm not trying to argue either way; I'm trying to point out a disconnect here.

[0]: https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/LICENS...

[1]: https://github.com/plausible/analytics/blob/2dd2f058d1dcae6f...

[2]: https://github.com/calcom/cal.com/blob/main/packages/feature...

[3]: https://github.com/PostHog/posthog/blob/master/ee/LICENSE

[4]: https://github.com/sidekiq/sidekiq/blob/main/COMM-LICENSE.tx...

Okay, back to our Rails app. In our app, the lifetime should be the whole Sidekiq process. Luckily, Sidekiq has internal documentation on how it runs. I won't copy the entire documentation here, just the part we are interested in:

Rollbar is a great error-tracking service. It alerts us on exceptions and errors, provides analysis tools and dashboard, so we can see, reproduce, and fix bugs quickly when something went wrong. This service has a possibility to log not only uncaught exceptions but any messages. By default, the messages are reported synchronously, but you can enable asynchronous reporting using Sidekiq, girl_friday, or Resque. Also, you can provide your own handler and a failover handler to be confident, that your error is tracked and delivered in the case of primary handler’s fail.

Hi there! I want to show off a little feature I made using hanami, htmx and a little bit of redis + sidekiq.

I'd say Sidekiq is the top competitor here.

There's something wrong at Redislabs, it took them over a year to get RESP3 rolled out into their hosted service, you'd expect a rollout of that to be a bit quicker when they're the owner of Redis.

It affected us when upgrading Sidekiq to version 7, which dropped support for older Redis, and their Envoy proxy setup didn't support HELLO and RESP3: https://github.com/sidekiq/sidekiq/issues/5594