💻 Хочете прокачати 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)

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

📊 Закон Прайса (Price’s Law)

“Квадратний корінь із загальної кількості людей у групі виконує приблизно половину всієї роботи.”

👨‍💻 Що це означає для розробників
• кілька ключових інженерів часто беруть на себе складні задачі;
• knowledge concentration може створювати ризики для проєкту;
• важливо ділитися контекстом і знаннями.

📊 Що це означає для менеджерів
• не варто перевантажувати найсильніших людей;
• потрібно вирівнювати експертизу через менторство;
• стабільність команди залежить від розподілу відповідальності.

💡 Простий приклад
У команді з 16 людей приблизно 4 можуть генерувати половину ключових технічних рішень.
Якщо ці люди перевантажені або вигорають — швидкість команди падає навіть при тій самій кількості розробників.

Як працювати з цим законом:
✔️ інвестувати в knowledge sharing
✔️ уникати “hero culture”
✔️ будувати процеси, а не залежність від окремих людей

💬 Сильна команда — це не кілька незамінних людей, а система, де знання розподілені і доступні кожному.

TikTok | Instagram | Telegram

Друзі, впевнені, що тут у чаті повно впевнених мідлів і сеньйорів, але ж точно є й ті, хто тільки придивляється до ІТ або думає зайти в усе це з нуля))

Звісно, золотих гір зараз ніхто не обіцяє, але це просто нормальна робота, яка багатьом дійсно кайфова. От ми й задумалися: а якби наші сеньйори опинилися на старті сьогодні?

Як виглядав би нормальний шлях? Тож підготували його для вас)

#codica_advice