Агов, друзі! ☕ До вашої ранкової кави ми підготували ще 5 побутових антипатернів у Rails, які здаються «ок», але потім болять 🎯

👉 Ці помилки часто роблять навіть досвідчені розробники – просто через спішку або звичку.
👉 Саме з таких дрібниць починається legacy 🤷

📌 Якщо ще не читав перші частини – обов’язково знайди в каналі:
🔘 частина 1 – про fat controller, god model, default_scope
🔘 частина 2 – про погано організовану бізнес-логіку

👇 Тож лови корисний чек-лист

1. Логіка прямо в

routes.rb

Rails.application.routes.draw do
  get "/hello", to: ->(env) { [200, {}, ["Hello, world!"]] }
end

❌ Проблема:
- Неочевидна поведінка
- Жодної авторизації
- Неможливо переюзати логіку

✅ Краще:

get "/hello", to: "welcome#hello"

Вся логіка в контролері, як і має бути 😉

2. Валідації тільки на фронтенді

<%= form.text_field :email, required: true %>

❌ Проблема:
- Користувач обійде через Postman
- У базу потрапить сміття

✅ Краще:

class User < ApplicationRecord
  validates :email, presence: true, format: { with: URI::MailTo::EMAIL_REGEXP }
end

Фронт – це для UX, бек – для безпеки й чистоти даних 🛡️

3. Відсутність strong parameters

def update
  @user.update(params[:user])
  redirect_to @user
end

❌ Проблема:
- Масове призначення (admin: true)
- Пряма вразливість у продакшені

✅ Краще:

def update
  if @user.update(user_params)
    redirect_to @user
  else
    render :edit
  end
end

private

def user_params
  params.require(:user).permit(:name, :email)
end

Strong params – твій маленький щит безпеки ✨

4. Створення даних у міграціях

class AddDefaultUsers < ActiveRecord::Migration[7.0]
  def change
    User.create!(name: "Admin", email: "[email protected]")
  end
end

❌ Проблема:
- Моделі змінюються, міграції – ні
- Через рік це просто впаде

✅ Краще:

# seeds.rb або окрема rake task
User.create!(name: "Admin", email: "[email protected]")

Міграції – тільки про схему. Дані – окремо. 📊

5. HTML у контролерах

def index
  render html: "<h1>Hello</h1>".html_safe
end

❌ Проблема:
- Повне змішування шарів
- Неможливо масштабувати

✅ Краще:

<!-- app/views/welcome/index.html.erb -->
<h1>Hello</h1>

Розділення логіки, представлення та даних – не просто принцип, а запорука виживання 💪

Висновок:
Rails дозволяє писати швидко, але це не завжди значить правильно. Пиши чисто одразу. Бо завтра це може редагувати твій колега. Або ти сам.

Хочеш ще антипатернів – кидай + в коментарі

#codica_advice

TikTok | Instagram | Telegram

Друзі, ну такого ви точно не очікували 😱
Ми запустили новий формат на YouTube – і перше відео одразу про найболючіше: зарплати в ІТ у 2025 💸

👉 Чи справді айтішникам у 2025 платять багато?
👉 І чому більшість цих грошей до тебе не долітає?

Ми зібрали факти, міфи та іронію, щоб чесно розповісти, що зараз відбувається з ринком.
Повірте, це відео ви додивитесь до кінця.

👉 Ловіть лінк і дивіться
Гарного перегляду!

TikTok | Instagram | Telegram

Навіщо JavaScript-тестування і що таке Cypress?

👉 Коли ваш проєкт росте, кількість коду збільшується в рази. Одне невелике оновлення може «поламати» зовсім іншу частину програми.

👉 І саме тут тести стають вашим страхуванням від багів.

#codica_advice

Чому саме Cypress?
Є безліч фреймворків для тестів у JS (Jest, Mocha, Playwright), але для end-to-end тестів сьогодні найбільше використовують Cypress. Це інструмент, який дозволяє симулювати поведінку реального користувача у браузері.

Що робить Cypress зручним?
🖥️ Тести у браузері
Ви бачите на власні очі, як відкривається сторінка, заповнюється форма й клікаються кнопки. Це схоже на «живу» перевірку.

🎛️ Візуальний інтерфейс
Не просто консоль, а цілий UI: можна поставити паузу, прогорнути виконання крок за кроком і подивитись, де саме тест впав.

📸 Скріншоти та відео
Якщо тест ламається на CI, Cypress робить знімок екрану або відеозапис. Зручно для відлагодження.

⚡ Гнучкість
Однаково добре працює з React, Vue, Angular та навіть з бекендом, якщо треба тестувати API.

⏳ Автоматичне очікування
Не потрібно писати

sleep()

– Cypress сам чекає, поки елемент з’явиться у DOM.

Мінімальний приклад

// cypress/e2e/login.cy.js
describe('Login flow', () => {
  it('користувач може увійти', () => {
    cy.visit('/login')
    cy.get('input[name=email]').type('[email protected]')
    cy.get('input[name=password]').type('Password1!')
    cy.contains('Sign in').click()
    cy.contains('Welcome').should('be.visible')
  })
})

🔍 У цьому прикладі Cypress «грає роль» користувача:
- відкриває сторінку

/login

- вводить email і пароль,
- клікає кнопку «Sign in»,
- перевіряє, що на екрані з’явився текст «Welcome».

✅ Можна сказати, що Cypress – це ваш інтерактивний робот-тестувальник, який клікає замість вас, і робить це без втоми та помилок.

💬 А ви вже пробували Cypress у своїх проєктах, чи поки що користуєтесь тільки unit-тестами на Jest/Mocha?

✨ Гарних вихідних, відпочиньте та набирайтеся сил!

#codica_advice

TikTok | Instagram | Telegram

Доброго ранку, друзі! Смакуйте каву, повторіть чарівні слова з картинки 3 рази, можливо щось зміниться 😄

Продуктивного усім робочого тижня!

#codica_humor

TikTok | Instagram | Telegram

Як відповідати на питання на співбесіді?

#codica_interviews

❌ Давати швидку відповідь без підготовки – погана ідея.
✅ Пройти ключові питання заздалегідь і зрозуміти, як пояснювати – правильний підхід.

1️⃣ Які бувають вимоги до тестування?
📌 Очікувана відповідь:
• Функціональні (що має робити система)
• Нефункціональні (швидкодія, безпека, зручність, сумісність тощо)
• Бізнес-вимоги (чого хоче досягти замовник)
• Технічні обмеження (платформи, інтеграції, середовище)

2️⃣ Що робити, якщо вимоги відсутні?
📌 Очікувана відповідь:
• Переглянути будь-яку доступну документацію (якщо є хоч щось).
• Обговорити з бізнесом або командою очікувану поведінку.
• Орієнтуватися на аналогічні системи або схожий функціонал.
• Прописати власні припущення та погодити їх із командою/PO.
• Виконати exploratory testing, щоб знайти очевидні баги навіть без формальних вимог.

3️⃣ Який тип/вид клас тестування має сенс автоматизувати?
📌 Очікувана відповідь:
• Регресійні – повторювані сценарії після кожного релізу.
• Smoke-тести – перевірка, що система взагалі стартує.
• Data-driven – один сценарій із різними наборами даних.
• API-тести – швидкі, стабільні, критично важливі для інтеграцій.
• Performance (частково) – коли важливо перевірити навантаження або стабільність.

❌ Що НЕ завжди має сенс автоматизувати:
– Одноразові або рідкісні сценарії.
– Тести з часто змінним UI.
– Дослідницькі (exploratory) тести, де важлива гнучкість.

🙌 Друзі, бажаємо вам легких та вдалих співбесід і гарного вечора!
До зустрічі завтра 🚀

TikTok | Instagram | Telegram