Merion Academy

Пятничная загадка: SQL-отчёт умножил выручку

В таблице orders у заказа №42 сумма 1000 ₽. У него две строки в order_items и два события в payments. Аналитик собирает отчёт:

SELECT o.id, SUM(o.total) AS revenue
FROM orders o
JOIN order_items i ON i.order_id = o.id
JOIN payments p ON p.order_id = o.id
GROUP BY o.id;

Для заказа №42 отчёт показывает 4000 ₽. В таблице orders одна строка, сумма там правильная. Ни одна таблица не содержит дублей по своему первичному ключу.

Почему получилось именно 4000 ₽?

👀 - SUM складывает значение total дважды: один раз до JOIN и ещё раз после
🔥- два JOIN создали четыре строки: 2 товара × 2 платежа
🤔- база округлила сумму из-за разных типов данных в таблицах

Ставь реакцию. Разбор и правильный запрос — в следующий понедельник.

Найти пользователей с шестью и более заказами — куда поставить условие? 🐸

SELECT user_id, COUNT(*) AS orders_count
FROM orders
GROUP BY user_id
HAVING COUNT(*) >= 6;

WHERE фильтрует строки до группировки. HAVING фильтрует группы после неё. Поэтому условие на COUNT(*) находится в HAVING.

Если нужны только оплаченные заказы, добавь условие раньше:

SELECT user_id, COUNT(*) AS paid_orders
FROM orders
WHERE status = 'paid'
GROUP BY user_id
HAVING COUNT(*) >= 6;

Строчка WHERE status = 'paid' убирает неоплаченные заказы до подсчёта. А HAVING оставляет пользователей, у которых оплаченных заказов шесть или больше.

Лайфхак для проверки: сначала запусти тот же запрос без HAVING и посмотри на суммы по нескольким знакомым user_id.

Если запрос из Node.js зависает слишком долго, то ставим дедлайн

Если проект использует встроенный fetch, укажи таймаут через AbortSignal.timeout:

const res = await fetch(url, {
signal: AbortSignal.timeout(5000)
});

Через 5 секунд сигнал отменит запрос. Ошибку всё равно нужно обработать: таймаут — ожидаемый сценарий при работе с сетью, а не повод ронять весь обработчик.

try {
const res = await fetch(url, { signal: AbortSignal.timeout(5000) });
if (!res.ok) throw new Error('HTTP ' + res.status);
} catch (err) {
console.error('Запрос не выполнен:', err);
}

Важно: таймаут ограничивает ожидание на стороне клиента; он не обещает, что сервер прекратит уже начатую работу.

Есть ли таймауты у внешних API, от которых зависит ваш сервис?

Разгадка пятничного кейса 🐸

Одна из вероятных причин – в зависимости useEffect попал объект или функция, которые создаются заново на каждом рендере. Эффект делает запрос → ответ меняет state → новый рендер создаёт новую зависимость → эффект снова делает запрос.

Проверка: сравнить значения зависимостей между рендерами и временно заменить составную зависимость на стабильный примитив, например status или page. Если цикл исчез, источник найден. В реальном проекте возможны и другие причины; одних 150 запросов для точного диагноза мало.

А теперь короткая ловушка Python:
def add(x, items=[]):
items.append(x)
return items

Что вернут подряд add(1) и add(2)? Список по умолчанию создаётся один раз при определении функции: ответы будут [1] и [1, 2].

Безопасный шаблон:
def add(x, items=None):
if items is None: items = []
items.append(x)
return items

И в React, и в Python - всё решает момент создания значения.

React отправляет запрос дважды? Сначала проверь причину 🐸

В разработке StrictMode может дополнительно запускать setup и cleanup эффекта. Это помогает заметить эффекты, которые нельзя безопасно повторить. В production такое дополнительное выполнение из-за StrictMode не происходит.

Но если запрос повторяется при каждом рендере, посмотри на зависимости:

const filters = { status: 'open' };
useEffect(() => { load(filters); }, [filters]);

Объект filters создаётся заново при каждом рендере. Для React это новая зависимость. Вынеси постоянное значение за пределы компонента или используй примитивные зависимости:

useEffect(() => { load(status); }, [status]);

И ещё: эффекту с запросом полезна отмена через AbortController, чтобы старый ответ не перезаписал свежий.

Сохрани пост на случай, когда в Network вдруг появятся одинаковые запросы.

Пятничная загадка: кто размножил запросы?

После небольшой правки React-страница стала открываться 8 секунд. Backend отвечает за 50 мс, база — за 20 мс, ошибок нет. В DevTools - около 150 одинаковых запросов к /api/items.

Факты расследования:
• проблема воспроизводится и в production-сборке;
• запрос запускается внутри useEffect;
• массив зависимостей эффекта заполнен;
• после каждого ответа компонент обновляет состояние;
• если убрать обновление состояния, шквал запросов прекращается.

Почему запрос запускается снова и снова?

👀 - виноват StrictMode: он дублирует запросы и в production
🔥 - в зависимостях эффекта есть объект или функция, которые создаются заново при каждом рендере
🤔 - браузер автоматически повторяет запрос, пока не получит ответ из кэша

Разгадка - в понедельник.

Задачка с собеса: почему список в React «путает» состояние строк? 🐸

Есть список задач. У каждой строки – поле ввода. Ты сортируешь список, и текст из первой строки внезапно оказывается у другой задачи. Данные в API правильные. Где ошибка?

Частая причина – key={index}. После сортировки индекс остался на позиции, а задача на этой позиции уже другая. React переиспользовал компонент и его локальное состояние.

Исправление: key={task.id} – стабильный идентификатор самой задачи. Он должен быть уникален среди соседних элементов и не меняться при сортировке.

На собеседовании за этим обычно спрашивают дальше: где хранить состояние, когда нужен useEffect, как обрабатывать формы и запросы к API. Эти темы разбираются на курсе «Frontend-разработка на React»: компоненты, JSX, состояние, события и работа с API.

➡️ Программа курса и бесплатная часть по ссылке

Мы тут с последним напоминанием

До конца закрытой акции Merion Academy осталось всего 5 часов.

Если присматривал курс себе или хотел отправить ссылку другу, сейчас последний момент. Сегодня скидки доходят до 70%, а после полуночи акция закончится.

Предложение действует только для участников нашей группы и их друзей.

Успеть выбрать курс со скидкой

Сделал `git reset` и «потерял» коммит? Проверь reflog 🐸

git log показывает историю текущей ветки. git reflog показывает, куда двигался HEAD локально, в том числе после reset и rebase.

План спасения:
git reflog -n 10
найди хеш нужного состояния, затем:
git switch -c rescue <хеш>

Теперь у тебя отдельная ветка с найденным коммитом. Проверь её через git log --oneline -5 и только потом решай, переносить ли коммит в рабочую ветку через cherry-pick.

⚠️ Reflog хранится локально и не бесконечно. На другом компьютере этих записей может не быть.

Какая команда Git однажды спасла тебе день?

Закрытая акция в честь Большой учительской недели

Большая учительская неделя пройдет с 28 сентября по 5 октября. В честь нее мы подготовили специальные скидки для участников нашей группы и их друзей.

Скидки действуют только два дня, 29 и 30 сентября.

В открытом доступе об этой акции не рассказываем. Предложением могут воспользоваться участники нашей группы и ваши друзья.

Скидка 70% на базовые тарифы следующих курсов:

• Data Science с нуля
• Мобильная разработка на Android
• Программирование на Kotlin
• Системный аналитик с нуля
• Нейросети с нуля
• Frontend React
• Redis для разработчиков и DevOps
• RabbitMQ для разработчиков и DevOps
• MongoDB для разработчиков и DevOps
• Node.js с нуля
• IP-АТС Asterisk с нуля
• Сетевые технологии Huawei
• GitLab CI/CD с нуля

Скидка 60% на базовые тарифы всех остальных курсов.

Скидка 50% на все тарифы с наставником.

Все скидки рассчитываются от полной стоимости.

Промокод: SCIENTIAESTLUX

Он уже добавлен во все ссылки, по дефолту вам добавлять руками ничего не нужно, но если вдруг будут трудности, прикрепили, чтобы он был под рукой.

Фронт сломался, в консоли тихо: 3 команды для проверки API

Страница не загружает данные? Проверь API напрямую через терминал.

1. Узнать статус ответа
curl -I https://site.ru/api/users

Покажет статус и заголовки. 404 - ошиблись в адресе, 401 или 403 - проблема с доступом, 500 - упал сервер.

2. Проверить, сколько отвечает сервер
curl -sS -o /dev/null -w "HTTP %{http_code} | %{time_total}s\n" https://site.ru/api/users

Увидишь код ответа и общее время запроса. Если API отвечает несколько секунд, фронт здесь ни при чём.

3. Посмотреть запрос целиком
curl -v https://site.ru/api/users

Команда покажет соединение, отправленные заголовки, редиректы и ответ сервера. Удобно, когда браузер пишет только Failed to fetch.

Если запрос работает в терминале, но падает в браузере, дальше проверь CORS, cookie и заголовок авторизации.

Процесс завис, что "убивать"?

kill не сработал, kill -9 кажется грубым, а какой именно PID мешает - непонятно

Собрали, как разбираться с процессами в Linux:

• найти виновника через ps и pgrep,
• понять разницу между kill, kill -9 и killall,
• отправить задачу в фон и вернуть обратно,
• не потерять запущенное при обрыве SSH.

В статье простым языком:
какие сигналы существуют, почему -9 это последнее средство и зачем нужен screen.

👉 Полная статья тут

Подключайтесь, вебинар начался https://www.youtube.com/live/nkxrGD4dqVY?si=QuXRU5BznwnnM4e5

Лягушата, сегодня в 19:00 по МСК начинаем наш вебинар – «Рынок IT сломался - куда идти прямо сейчас». Трансляция будет на Youtube. Ссылку скинем сюда, когда начнется.

Поднимаешь стек из пяти контейнеров руками и каждый раз заново?

docker run с десятью флагами, потом ещё один, потом сеть между ними - и всё это снова после перезагрузки.

Собрали, как это делается через docker-compose:
• один файл вместо простыни команд,
• зависимости между сервисами: база поднимается раньше приложения,
• переменные окружения и тома, чтобы данные не терялись,
• запуск и остановка всего стека одной командой.

💡 В статье простым языком: структура compose-файла, самые нужные директивы и грабли, на которые наступают все.

Полная статья тут.

Задачка с собеса: в сети завёлся хост, который каждые 10 минут стучится на незнакомый адрес. Твои действия? 🐸

Самый частый ответ - «заблокировать». И самый неудачный: заблокируешь - потеряешь возможность понять, что вообще происходило.

Порядок примерно такой:

• кто это физически - по MAC и логам DHCP найти конкретное устройство, а не «айпишник в сети»
• куда стучится - whois, обратная зона, репутация адреса. Иногда это просто телеметрия вендора
• чем стучится - снять трафик и посмотреть: шифровано, сколько данных, в какую сторону их больше
• когда началось - логи файрвола за месяц. Важно не «сейчас», а «с какого дня»
• кто ещё - один хост это инцидент, десять это уже кампания

Второй вопрос собеса: а если это принтер? Или камера? Или, как в загадке на прошлой неделе, термометр в аквариуме?

Третий, самый неудобный: как докажешь, что данные утекли, а не просто устройство пинговало обновления?

Вот это и есть работа безопасника - не «знать, что бывают утечки», а уметь разложить инцидент по шагам. Разбираем в курсе «Кибербезопасность»: атаки и их механика, защита периметра и сети, разбор инцидентов.

Если интереснее со стороны атакующего - есть «Этичный хакинг»: Kali Linux, типовые уязвимости, своя лаборатория.

У обоих доступна бесплатная часть курса.

➡️ Кибербезопасность
➡️ Этичный хакинг

Разгадка пятничного чгк

Внутрь просто не пускало. Электронные пропуска и системы доступа работали через ту же инфраструктуру, которая легла.

А сам сбой начался с плановой проверки: выполнили команду, чтобы оценить доступность сети, и она вырубила соединения между дата-центрами. Дальше сработала автоматика - серверы, отвечающие за адреса, решили, что они «нездоровы», и убрали свои маршруты из интернета. Соцсеть исчезла с карты мира.

Речь про Facebook и 4 октября 2021 года. Шесть часов простоя.

Отдельно жаль тех, кто в тот день объяснял руководству, что войти в систему нельзя, потому что нельзя войти в систему 🐸

А у тебя доступ к инфраструктуре зависит от той же сети, что может упасть?
😱 - конечно, а как иначе
🤓 - есть отдельный канал, мы не первый день живём

👇 Жмите на реакцию

Время пятничной загадки.

Крупнейшая соцсеть мира пропадает из интернета целиком. Не тормозит - её просто нет: сайт, приложение, мессенджер, всё.

Инженеры примерно понимают, что случилось. Проблема в том, что они не могут ничего сделать: внутренние системы лежат вместе со всем остальным, потому что зависят от той же сети.

Тогда несколько человек садятся в машину и едут в дата-центр чинить руками. Приезжают. И тут их ждёт следующий сюрприз.

Вопрос: что пошло не так на месте?

👀 - у дежурной смены не было прав на нужное оборудование
🔥 - двери не открывались: пропускная система тоже работала через упавшую сеть
🤣 - нужный шкаф был заперт, а ключ - у сотрудника в отпуске

👇 Жми на реакцию, разгадка в понедельник

Ребят, привет.

23 сентября в 19:00 проводим бесплатный вебинар «Рынок IT сломался - куда идти прямо сейчас».

Разберём, что происходит с наймом и вилками, что забрал ИИ, а что нет, и в какую нишу заходить сейчас. Вебинар проведет Никита Карасёв, fullstack-разработчик, сейчас пишет фронт в финтехе, автор курсов в нашей академии. Много лет успешно совмещает работу в IT и жизнь в солнечных странах, а еще он просто интересный собеседник и его опыт может быть для вас полезен.

Прийти можно без регистрации. В день вебинара мы пришлем ссылку в канале, но если боитесь пропустить - оставьте почту, пришлём напоминание с ссылкой в день эфира.

Ссылка на запись.