💻 Хочете прокачати SQL на практиці?

#codica_advice

Знайомтеся — SQLGuru, інтерактивний тренажер для тих, хто хоче навчитися писати SQL-запити, а не просто читати про них.

🎯 Підійде:
— новачкам, які тільки вивчають SQL;
— аналітикам, які хочуть більше практики;
— тим, хто готується до співбесіди або хоче освіжити знання.

Замість сухого синтаксису — інтерактивні завдання та практика. Можна тренуватися у зручному форматі й поступово ускладнювати задачі.

👉 Спробувати SQLGuru

🎥 Огляд тренажера

📌 Зберігайте, щоб не загубити, і практикуйте SQL регулярно!

TikTok | Instagram | Telegram

🤖 Ураа, друзі, знову квіззз! Але цього разу — про наш із вами улюблений ШІ.

Сьогодні тільки хардкорні питання 😎

Ану гайда перевіряти свої знання!

TikTok | Instagram | Telegram

🤯 «Знову бізнес-логіка в контролері, а ActiveRecord-модель роздулася до 1000 рядків?» — знайомий біль у Rails-проектах?

Коли додаток росте, стандарти validates у моделях починають заважати: вони прив’язані до бази даних і підходять для простих перевірок, але ламаються на складній бізнес-логіці (наприклад, різна валідація для Admin API та Mobile API).

Рішення, яке ставлять у вимоги на Senior/Lead позиціях — використання екосистеми dry-rb, зокрема dry-validation та dry-monads.

Показуємо, як винести валідацію та бізнес-логіку з моделей у ізольовані Service Objects за 3 кроки:

1️⃣ Виносимо складну валідацію в Contract (dry-validation):

class UserRegistrationContract < Dry::Validation::Contract
  params do
    required(:email).filled(:string)
    required(:age).filled(:integer)
  end

  rule(:email) do
    unless /\A[\w+\-.]+@[a-z\d\-.]+\.[a-z]+\z/i.match?(value)
      key.failure("має бути коректним email-ом")
    end
  end

  rule(:age) do
    key.failure("реєстрація доступна лише з 18 років") if value < 18
  end
end

2️⃣ Використовуємо dry-monads для чистого повернення результату (Success/Failure):

class RegisterUser
  include Dry::Monads[:result]

  def call(params)
    # 1. Валідуємо параметри
    contract_result = UserRegistrationContract.new.call(params)
    return Failure(contract_result.errors.to_h) if contract_result.failure?

    # 2. Створюємо користувача (бізнес-логіка)
    user = User.create!(contract_result.to_h)
    Success(user)
  rescue ActiveRecord::RecordNotUnique
    Failure(email: ["цей email вже зайнятий"])
  end
end

3️⃣ Тонкий і чистий контролер:

class UsersController < ApplicationController
  def create
    case RegisterUser.new.call(user_params)
    in Dry::Monads::Success(user)
      render json: user, status: :created
    in Dry::Monads::Failure(errors)
      render json: { errors: errors }, status: :unprocessable_entity
    end
  end
end

🔥 Чому це оцінять на співбесіді та в коді:
• Single Responsibility: Модель відповідає ТІЛЬКИ за роботу з БД, Контракт — за валідацію, Сервіс — за бізнес-логіку.
• Відсутність "брудних" exceptions: Замість raise/rescue ми контрольовано повертаємо Success або Failure (Railway Oriented Programming).
• Тестувати такі контракти та сервіси в RSpec — суцільне задоволення, бо вони не потребують підйому бази даних.

А як ви виносити складну логіку з моделей у своїх проектах: використовуєте dry-rb, ActiveInteraction чи старі добрі PORO-сервіси? 👇

TikTok | Instagram | Telegram

🧠 13 законів розробки

Друзі, у кожній команді рано чи пізно помічаєш одну цікаву закономірність: невелика частина людей створює більшу частину результату. Це не про “кращих” чи “гірших”, а про природну динаміку досвіду, фокусу та залученості в роботі.

Закони, які вже розглянули:
👉 Закон Паркінсона
👉 Закон Хофштедтера
👉 Закон Брукса
👉 Закон Конвея (і зворотний закон Конвея)
👉 Закон Каннінгема
👉 Закон Стерджена
👉 Закон Завінскі (Zawinski’s Law)
👉 Закон Хайрума (Hyrum’s Law)

Сьогодні — закон, який часто згадують у контексті продуктивності команд 👇