get-smart 0.0.1

data/files/rails/authentication_and_authorization/beginner/sessions_controller_setup.md

@@ -0,0 +1,43 @@
+## 🔒 Create `SessionsController` for Login/Logout
+
+A sessions controller is the conventional way to manage user login and logout. You will handle setting and clearing the `session[:user_id]` to track signed‐in users.
+
+1. Generate the controller:
+
+```bash
+rails generate controller Sessions new create destroy
+```
+
+2. Implement login and logout actions:
+
+```ruby
+class SessionsController < ApplicationController
+  def new
+  end
+
+  def create
+    user = User.find_by(email: params[:email])
+    if user&.authenticate(params[:password])
+      session[:user_id] = user.id
+      redirect_to root_path, notice: 'Logged in successfully'
+    else
+      flash.now[:alert] = 'Invalid email or password'
+      render :new
+    end
+  end
+
+  def destroy
+    session.delete(:user_id)
+    redirect_to login_path, notice: 'Logged out successfully'
+  end
+end
+```
+
+3. Add routes:
+
+```ruby
+# config/routes.rb
+get 'login', to: 'sessions#new'
+post 'login', to: 'sessions#create'
+delete 'logout', to: 'sessions#destroy'
+```

data/files/rails/authentication_and_authorization/beginner/simple_role_authorization.md

@@ -0,0 +1,42 @@
+## 🎩 Implement Simple Role-Based Authorization
+
+For basic authorization, add a `role` attribute to your `User` model and check it in controllers or views. This allows granting admin or other privileges easily.
+
+1. Add `role` to users (e.g., `:user` or `:admin`):
+
+```bash
+rails generate migration AddRoleToUsers role:string
+rails db:migrate
+```
+
+2. Set a default role in the model:
+
+```ruby
+class User < ApplicationRecord
+  has_secure_password
+  after_initialize :set_default_role, if: :new_record?
+
+  def set_default_role
+    self.role ||= 'user'
+  end
+
+  def admin?
+    role == 'admin'
+  end
+end
+```
+
+3. Restrict access in controllers:
+
+```ruby
+class Admin::DashboardController < ApplicationController
+  before_action :require_login
+  before_action :require_admin
+
+  private
+
+  def require_admin
+    redirect_to root_path, alert: 'Access denied' unless current_user&.admin?
+  end
+end
+```

data/files/rails/authentication_and_authorization/expert/cancancan_ability_caching_preload.md

@@ -0,0 +1,36 @@
+## ⚡ Cache and Preload Permissions in Cancancan for High-Volume Queries
+
+When serving large data sets, repeatedly evaluating `current_ability.can?` or using `accessible_by` can be a bottleneck. You can serialize and cache the user’s Ability object in Redis, and preload IDs via single optimized SQL for bulk authorization. This minimizes Ruby-level checks and dramatically reduces query count.
+
+```ruby
+# app/controllers/application_controller.rb
+class ApplicationController < ActionController::Base
+  def current_ability
+    Rails.cache.fetch([:ability, current_user.id], expires_in: 10.minutes) do
+      Ability.new(current_user)
+    end
+  end
+end
+```
+
+```ruby
+# app/models/ability.rb
+class Ability
+  include CanCan::Ability
+
+  def initialize(user)
+    user ||= User.new
+    if user.admin?
+      can :manage, :all
+    else
+      # Preload allowed project IDs in one go
+      project_ids = Project.where(public: true)
+                           .or(Project.where(owner_id: user.id)).pluck(:id)
+      can :read, Project, id: project_ids
+      # further rules...
+    end
+  end
+end
+```
+
+This approach consolidates permission evaluation into a single SQL pluck and reuses the compiled Ability, dramatically speeding up index actions or GraphQL batch loads.

data/files/rails/authentication_and_authorization/expert/dynamic_pundit_scope_with_rls.md

@@ -0,0 +1,30 @@
+## 🛡️ Leverage Pundit Scopes with Postgres Row-Level Security
+
+Combining Pundit’s `Scope` objects with Postgres RLS pushes authorization logic into the database, eliminating N+1 policy checks and preventing accidental bypasses. You can define RLS policies that mirror your Pundit scopes, then use a minimal scope in Ruby to apply any dynamic filters.
+
+```sql
+-- db/migrate/20240101000000_add_rls_to_projects.rb
+enable_extension 'pgcrypto';
+
+enable_row_level_security 'projects';
+
+CREATE POLICY user_projects_policy ON projects
+  USING (owner_id = current_setting('app.current_user_id')::uuid);
+```
+
+```ruby
+# app/policies/project_policy.rb
+class ProjectPolicy < ApplicationPolicy
+  class Scope < Scope
+    def resolve
+      # Set the current_user in Postgres and let RLS do the heavy lifting
+      ActiveRecord::Base.connection.execute(
+        "SET app.current_user_id = '#{user.id}'"
+      )
+      scope.all
+    end
+  end
+end
+```
+
+This offloads filtering into the database, scales to millions of rows, and ensures policy constraints are enforced even in complex SQL joins or background jobs.

data/files/rails/authentication_and_authorization/expert/graphql_jwt_pundit_integration.md

@@ -0,0 +1,40 @@
+## 🔑 Secure GraphQL Resolvers with JWT Authentication and Pundit
+
+For API-first Rails apps, authenticating and authorizing GraphQL resolvers at the same time maintains a unified permission model. Decode the JWT in your GraphQL controller, set `current_user`, and pass a Pundit context into the schema. Use `authorize!` in resolvers to guard individual fields or mutations.
+
+```ruby
+# app/controllers/graphql_controller.rb
+class GraphqlController < ApplicationController
+  def execute
+    token = request.headers['Authorization']&.split(' ')&.last
+    context = { current_user: authenticate_jwt(token) }
+    result = MySchema.execute(
+      params[:query], variables: params[:variables], context: context
+    )
+    render json: result
+  end
+
+  private
+
+  def authenticate_jwt(token)
+    payload = JWT.decode(token, Rails.application.secrets.jwt_secret)[0]
+    User.find(payload['sub'])
+  rescue JWT::DecodeError
+    nil
+  end
+end
+```
+
+```ruby
+# app/graphql/types/query_type.rb
+field :project, Types::ProjectType, null: false do
+  argument :id, ID, required: true
+end
+def project(id:)
+  project = Project.find(id)
+  Pundit.authorize(context[:current_user], project, :show?)
+  project
+end
+```
+
+This pattern ensures every GraphQL field is wrapped in Pundit’s authorization checks while centralizing token decoding logic.

data/files/rails/authentication_and_authorization/expert/mfa_custom_warden_strategy.md

@@ -0,0 +1,30 @@
+## 🔒 Implement Multi-Factor Authentication with a Custom Warden Strategy
+
+Adding a second authentication factor at the Warden layer lets you enforce 2FA at the lowest possible point and fail early. You can define a custom strategy that checks a one-time password (OTP) after Devise’s primary authentication, then inject it into `Devise.warden`. This ensures your entire app benefits from the same flow without polluting controllers.
+
+```ruby
+# config/initializers/warden.rb
+Rails.application.config.middleware.use Warden::Manager do |manager|
+  manager.default_strategies scope: :user, strategies: [:database_authenticatable, :otp_authenticatable]
+  manager.failure_app = Devise::FailureApp
+end
+
+Warden::Strategies.add(:otp_authenticatable) do
+  def valid?
+    params['user'] && params['user']['otp_code']
+  end
+
+  def authenticate!
+    user = User.find_by(email: params['user']['email'])
+    return fail! unless user&.valid_password?(params['user']['password'])
+
+    if user.validate_and_consume_otp!(params['user']['otp_code'])
+      success!(user)
+    else
+      fail!('Invalid OTP code')
+    end
+  end
+end
+```
+
+Then in your Devise sessions controller, prompt for OTP on the second step, verifying via the above strategy. This approach cleanly composes with Devise’s pipeline and ensures uniform failure handling.

data/files/rails/authentication_and_authorization/middle/customize_redirects.md

@@ -0,0 +1,16 @@
+## 🔄 Customize Post-Login Redirects
+
+When using Devise, you can override `after_sign_in_path_for` to redirect users based on their roles or preferences. This ensures admins land on a dashboard while regular users go to the homepage. Simply add the override in `ApplicationController` or a custom sessions controller.
+
+```ruby
+class ApplicationController < ActionController::Base
+  # Redirect users after login based on role
+  def after_sign_in_path_for(resource)
+    if resource.admin?
+      admin_dashboard_path
+    else
+      root_path
+    end
+  end
+end
+```

data/files/rails/authentication_and_authorization/middle/policy_scope_index.md

@@ -0,0 +1,29 @@
+## 📜 Leverage policy_scope in Index Actions
+
+Pundit's `policy_scope` helps you filter records a user is allowed to view. Instead of fetching all records, use `policy_scope` in your controller's `index` action to apply the policy scope automatically.
+
+```ruby
+class ArticlesController < ApplicationController
+  before_action :authenticate_user!
+  def index
+    # Only returns articles the user is authorized to see
+    @articles = policy_scope(Article)
+  end
+end
+```
+
+Then define the scope in `ArticlePolicy`:
+
+```ruby
+class ArticlePolicy < ApplicationPolicy
+  class Scope < Scope
+    def resolve
+      if user.admin?
+        scope.all
+      else
+        scope.where(published: true)
+      end
+    end
+  end
+end
+```

data/files/rails/authentication_and_authorization/middle/role_based_policies.md

@@ -0,0 +1,19 @@
+## 🔑 Implement Role-Based Access in Policies
+
+Use Pundit policies to enforce role checks cleanly. Define helper methods like `admin?` or `editor?` and reference them in each action method to keep your controllers thin and policies expressive.
+
+```ruby
+class UserPolicy < ApplicationPolicy
+  def show?
+    user.admin? || record.id == user.id
+  end
+
+  def update?
+    user.admin? || (user.editor? && record.section == user.section)
+  end
+
+  def destroy?
+    user.admin?
+  end
+end
+```

data/files/rails/authentication_and_authorization/middle/token_authentication.md

@@ -0,0 +1,22 @@
+## 🔒 Setup Token-Based API Authentication
+
+Combine Devise and `devise-jwt` to secure your Rails API with JSON Web Tokens. This approach lets clients authenticate once and include the JWT in `Authorization` headers for subsequent requests.
+
+```ruby
+# Gemfile
+gem 'devise'
+gem 'devise-jwt'
+
+# app/models/user.rb
+devise :database_authenticatable, :jwt_authenticatable,
+       jwt_revocation_strategy: JwtDenylist
+
+# config/initializers/devise.rb
+Devise.setup do |config|
+  config.jwt do |jwt|
+    jwt.secret = Rails.application.credentials.fetch(:secret_key_base)
+    jwt.dispatch_requests = [['POST', %r{^/login$}]]
+    jwt.revocation_requests = [['DELETE', %r{^/logout$}]]
+  end
+end
+```

data/files/rails/background_jobs/advanced/idempotent_jobs.md

@@ -0,0 +1,21 @@
+## 🔑 Implementing Idempotent Jobs with Sidekiq Unique Jobs
+
+To prevent duplicate job execution, integrate the `sidekiq-unique-jobs` gem. It locks jobs with the same arguments until completion, ensuring idempotency for critical operations.
+
+```ruby
+# Gemfile
+gem 'sidekiq-unique-jobs'
+
+# app/jobs/send_report_job.rb
+class SendReportJob
+  include Sidekiq::Worker
+  sidekiq_options unique: :until_executed,
+                  unique_args: ->(args) { ["SendReport", args.first] }
+
+  def perform(user_id)
+    # expensive report generation logic
+  end
+end
+```
+
+Configure lock expiry in `config/initializers/sidekiq.rb` to fine‑tune dedupe windows.

data/files/rails/background_jobs/advanced/job_metrics.md

@@ -0,0 +1,15 @@
+## 📊 Instrumenting Jobs with ActiveSupport::Notifications
+
+Track job durations and failures by subscribing to the `perform.active_job` event. Push metrics to your preferred monitoring system for real‑time insights.
+
+```ruby
+# config/initializers/job_metrics.rb
+ActiveSupport::Notifications.subscribe('perform.active_job') do |name, start, finish, id, payload|
+  duration_ms = (finish - start) * 1000
+  status = payload[:exception] ? 'error' : 'success'
+  StatsD.increment("jobs.#{payload[:job].class.name}.#{status}")
+  StatsD.timing("jobs.#{payload[:job].class.name}.duration", duration_ms)
+end
+```
+
+Each job invocation emits metrics like `jobs.ProcessOrderJob.success` and timing data, empowering performance tuning.

data/files/rails/background_jobs/advanced/rate_limiting_middleware.md

@@ -0,0 +1,35 @@
+## ⚡️ Throttling Jobs with Custom Rate-Limiting Middleware
+
+Introduce a Sidekiq server middleware to throttle job execution by namespace or user, controlling throughput and respecting external API rate limits.
+
+```ruby
+# lib/sidekiq/middleware/server/rate_limiter.rb
+module Sidekiq
+  module Middleware
+    module Server
+      class RateLimiter
+        def call(worker, job, queue)
+          key = "rate:#{worker.class.name}"
+          if Redis.current.incr(key) > 100
+            # re‑enqueue after delay when limit exceeded
+            worker.class.perform_in(1.minute, *job['args'])
+          else
+            yield
+          end
+        ensure
+          Redis.current.expire(key, 60)
+        end
+      end
+    end
+  end
+end
+
+# config/initializers/sidekiq.rb
+Sidekiq.configure_server do |config|
+  config.server_middleware do |chain|
+    chain.add Sidekiq::Middleware::Server::RateLimiter
+  end
+end
+```
+
+This code enforces a maximum of 100 jobs per minute per worker class.

data/files/rails/background_jobs/advanced/sidekiq_batches.md

@@ -0,0 +1,27 @@
+## 📦 Grouping Jobs with Sidekiq Batches and Callbacks
+
+Sidekiq Pro's Batches allow coordination of many jobs and execute callbacks when the group finishes. Use them to orchestrate workflows across multiple worker classes.
+
+```ruby
+# app/services/data_import_service.rb
+class DataImportService
+  def import_all(records)
+    batch = Sidekiq::Batch.new
+    batch.description = 'Importing CSV rows'
+    batch.on(:success, ImportCallback)
+
+    batch.jobs do
+      records.each { |row| ImportRowJob.perform_async(row.to_h) }
+    end
+  end
+end
+
+# app/workers/import_callback.rb
+class ImportCallback
+  def on_success(status, options)
+    ReportsMailer.import_finished.deliver_now
+  end
+end
+```
+
+This yields atomic workflows, notifying you when all `ImportRowJob` instances complete.

data/files/rails/background_jobs/advanced/transactional_enqueue.md

@@ -0,0 +1,18 @@
+## ⚙️ Ensuring Transactional Enqueue
+
+When enqueueing jobs from ActiveRecord callbacks, using `after_commit` guarantees the job is only scheduled once the database transaction succeeds. This prevents orphaned jobs when transactions roll back.
+
+```ruby
+# app/models/order.rb
+class Order < ApplicationRecord
+  after_commit :enqueue_order_processing
+
+  private
+
+  def enqueue_order_processing
+    ProcessOrderJob.perform_later(self.id)
+  end
+end
+```
+
+This ensures `ProcessOrderJob` never runs on a failed transaction, preserving data consistency.

data/files/rails/background_jobs/beginner/create_simple_job.md

@@ -0,0 +1,20 @@
+## ⚙️ Create a Simple Active Job
+
+Rails’ Active Job provides a standard interface for queueing jobs. Generate a new job and implement your business logic in the `perform` method.
+
+```bash
+# generate a job named HardWorker
+rails generate job HardWorker
+```
+
+```ruby
+# app/jobs/hard_worker_job.rb
+class HardWorkerJob < ApplicationJob
+  queue_as :default
+
+  def perform(*args)
+    # Your background task goes here
+    puts "Working hard on: #{args.inspect}"
+  end
+end
+```

data/files/rails/background_jobs/beginner/enqueue_with_perform_later.md

@@ -0,0 +1,20 @@
+## 🚀 Enqueue Jobs with `perform_later`
+
+Use `perform_later` to push your job onto the queue. This call returns immediately, letting web requests finish faster.
+
+```ruby
+# In a controller action
+class ReportsController < ApplicationController
+  def create
+    # Enqueue the job and pass the report ID
+    ReportGenerationJob.perform_later(current_user.id)
+    redirect_to reports_path, notice: "Report is being generated!"
+  end
+end
+```
+
+```bash
+# Or from Rails console:
+rails c
+ReportGenerationJob.perform_later(42)
+```

data/files/rails/background_jobs/beginner/install_sidekiq.md

@@ -0,0 +1,31 @@
+## 🛠️ Install and Configure Sidekiq
+
+Sidekiq is a popular background job processor that integrates seamlessly with Rails. Add the gem and configure Rails to use Sidekiq as the Active Job adapter so all your jobs run through it.
+
+```ruby
+# Gemfile
+gem 'sidekiq'
+```
+
+```bash
+# then install
+bundle install
+```
+
+In `config/application.rb` or in your specific environment config (`config/environments/development.rb`):
+
+```ruby
+# config/application.rb
+module YourApp
+  class Application < Rails::Application
+    # Use Sidekiq for background jobs
+    config.active_job.queue_adapter = :sidekiq
+  end
+end
+```
+
+Make sure to start a Redis server and then launch Sidekiq with:
+
+```bash
+bundle exec sidekiq
+```

data/files/rails/background_jobs/beginner/monitor_sidekiq_web.md

@@ -0,0 +1,17 @@
+## 🔍 Monitor Jobs with Sidekiq Web
+
+Sidekiq provides a web UI to view queues, retries, and job stats. Mount it in your routes and secure access.
+
+```ruby
+# config/routes.rb
+require 'sidekiq/web'
+
+Rails.application.routes.draw do
+  authenticate :user, lambda { |u| u.admin? } do
+    mount Sidekiq::Web => '/sidekiq'
+  end
+  # ... your other routes
+end
+```
+
+Visit `http://localhost:3000/sidekiq` to see real-time job dashboards and retry failed jobs.

data/files/rails/background_jobs/beginner/pass_arguments_to_job.md

@@ -0,0 +1,20 @@
+## 📦 Pass Arguments to Your Job
+
+Jobs can accept arguments which are serialized to JSON. This lets you pass simple data like IDs or strings safely.
+
+```ruby
+# app/jobs/send_notification_job.rb
+class SendNotificationJob < ApplicationJob
+  queue_as :mailers
+
+  def perform(user_id, message)
+    user = User.find(user_id)
+    UserMailer.alert(user, message).deliver_now
+  end
+end
+```
+
+```ruby
+# enqueue with multiple params
+SendNotificationJob.perform_later(7, "Your report is ready!")
+```

data/files/rails/background_jobs/expert/custom_retry_strategy.md

@@ -0,0 +1,24 @@
+## 🔧 Custom Retry Strategies & Exponential Backoff in Sidekiq
+
+Override Sidekiq’s default retry logic by defining `sidekiq_options` and using middleware or `sidekiq_retries_exhausted` hooks. This allows you to implement exponential backoff, route exhausted messages to a DLQ, or notify engineers automatically.
+
+```ruby
+class HardWorker
+  include Sidekiq::Worker
+  sidekiq_options retry: 7, backtrace: true
+
+  sidekiq_retry_in do |count|
+    # exponential backoff: 10s, 60s, 300s, …
+    (10**count) + rand(30)
+  end
+
+  sidekiq_retries_exhausted do |msg, ex|
+    DeadLetterJob.perform_async(msg['class'], msg['args'], ex.message)
+  end
+
+  def perform(*args)
+    # potentially flaky logic
+    do_something_risky!
+  end
+end
+```

data/files/rails/background_jobs/expert/job_orchestration.md

@@ -0,0 +1,27 @@
+## 🔄 Sequential Job Orchestration with ActiveJob Callbacks
+
+Leverage ActiveJob callbacks to construct complex, multi‐step workflows while preserving transactional integrity. Use callbacks like `after_perform_commit`, `before_enqueue`, and `rescue_from` to chain jobs, handle failures, and retry only on successful DB commits.
+
+```ruby
+class FirstJob < ApplicationJob
+  after_perform_commit :enqueue_second
+  rescue_from(StandardError) { |e| ErrorNotifierJob.perform_later(self.job_id, e.message) }
+
+  def perform(record_id)
+    record = Record.find(record_id)
+    record.process_part_one!  # may raise ActiveRecord::Rollback
+  end
+
+  private
+
+  def enqueue_second
+    SecondJob.perform_later(record_id)
+  end
+end
+
+class SecondJob < ApplicationJob
+  def perform(record_id)
+    Record.find(record_id).process_part_two!
+  end
+end
+```

data/files/rails/background_jobs/expert/observability_instrumentation.md

@@ -0,0 +1,18 @@
+## 📊 Advanced Observability via ActiveSupport::Notifications
+
+Instrument background jobs for latency, success/failure rates, and custom metrics by subscribing to `perform.active_job` or Sidekiq server events. Push timings to Datadog, StatsD, or Prometheus for real‑time dashboards and alerting.
+
+```ruby
+# config/initializers/job_instrumentation.rb
+ActiveSupport::Notifications.subscribe('perform.active_job') do |name, start, finish, id, payload|
+  duration_ms = (finish - start) * 1000
+  StatsD.timing("jobs.duration", duration_ms, tags: ["job:#{payload[:job]}"])
+  StatsD.increment("jobs.completed", tags: ["status:#{payload[:exception] ? 'error' : 'ok'}"])
+end
+
+Sidekiq.configure_server do |config|
+  config.server_middleware do |chain|
+    chain.add Sidekiq::Middleware::Server::Statsd, namespace: 'sidekiq'
+  end
+end
+```

data/files/rails/background_jobs/expert/sidekiq_batch_callbacks.md

@@ -0,0 +1,22 @@
+## 📦 High‑Throughput Batch Processing with Sidekiq::Batch
+
+When you need to launch hundreds or thousands of jobs as a unit and track completion, Sidekiq Pro’s `Batch` API is indispensable. You can attach callbacks for success, death, or custom events to execute cleanup or next‐phase tasks once the batch completes.
+
+```ruby
+batch = Sidekiq::Batch.new
+batch.description = "Bulk user data refresh"
+batch.on(:success, 'BatchCallback#on_success', { report_id: 42 })
+
+batch.jobs do
+  User.find_in_batches(batch_size: 1000) do |group|
+    RefreshUserJob.perform_async(group.map(&:id))
+  end
+end
+
+# app/workers/batch_callback.rb
+class BatchCallback
+  def self.on_success(status, options)
+    ReportMailer.batch_finished(options[:report_id], status.total).deliver_now
+  end
+end
+```

data/files/rails/background_jobs/expert/unique_jobs_idempotency.md

@@ -0,0 +1,24 @@
+## 🔒 Idempotency & Deduplication with sidekiq‑unique‑jobs
+
+Prevent duplicate executions by leveraging the `sidekiq-unique-jobs` gem. Configure locks to ensure only one job per unique key is enqueued or executing at any time, and auto‑expire stale locks to avoid deadlocks in rare failure modes.
+
+```ruby
+class SyncUserJob
+  include Sidekiq::Worker
+  sidekiq_options(
+    unique: :while_executing,
+    lock_expiration: 4.hours,
+    queue: :sync
+  )
+
+  def perform(user_id)
+    user = User.find(user_id)
+    ExternalApi.sync(user)
+  end
+end
+```
+
+Lock types:
+- `:until_executing` — lock until job begins
+- `:while_executing` — lock during execution
+- `:until_executed` — lock until execution finishes