А что выберешь ты?
🐝 - пасека
💻 - опять фиксить баги

SQL на собесах

На собеседованиях часто дают задачи по алгоритмам, но SQL-задачи тоже встречаются часто. Их могут дать любому бэкенд разработчику, независимо от языка программирования.

Чтобы повысить свои шансы на оффер, нужно уметь быстро писать простые SQL-запросы. Для этого нужна практика.

Для алгоритмов есть LeetCode, а сегодня я хочу поделиться хорошим сборником задач на SQL с автопроверкой — SQL-EX.

Там есть задания на различные механизмы SQL: от простых SELECT и JOIN до оконных функций, подзапросов и предикатов. Под каждой задачей есть ссылка на теоретический материал.

Вот ссылка на SQL-EX: https://sql-ex.ru/

Найти максимальную цену ПК, выпускаемых каждым производителем, у которого есть модели в таблице PC.

Схема БД:
 - Product (maker, model, type)
 - PC (code, model, speed, ram, hd, cd, price)

Вывести производитей и их максимальные цены.

Свое решение выложил в комментариях 👇

Фактор автобуса | Как измерить взаимозаменяемость команды 🚌

Есть такое понятие в управлении командой - Bus Factor (Фактор автобуса).
Bus Factor — это метрика, показывающая, насколько зависима команда от отдельных сотрудников. Это полезный показатель, чтобы оценить риски, если важный человек из команды внезапно выйдет из строя, например заболеет или уволится. Но как его измерить?

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

Например у нас в команде есть
- Алина - backend разработчик
- Коля - backend разработчик
- Вася - backend разработчик
- Женя - frontend разработчик
- Маша - frontend разработчик
- Анатолий - тимлид, frontend разработчик

Пусть в нашей команде только тимлид Анатолий знает, какие задачи нужно делать в следующем спринте, причем он это нигде не записал, и планирует рассказать команде о новых задачах на созвоне в понедельник.

И вот в пятницу вечером после работы Анатолия сбивает автобус. Все, команда не знает что делать, работа остановлена.
Если Анатолий не передал команде четких инструкций и не прописал задачи в системе управления, то команда теряет ориентацию и не может эффективно продолжить работу.

Для этой команды Bus factor - 1️⃣

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

Команда конечно будет грустить, но продолжит делать задачи по заранее составленному плану, а после релза пойдет навестить лида в травмпункт.

Автобусу, если его водитель - представитель конкурирующей компании, нужно сбить еще двух frontend разработчиков, чтобы остановить работу команды. (И то не полностью, бэкендеры продолжат перекладывать джейсоны)

В таком случае bus factor - 3️⃣

А у вас в команде какой Bus Factor? Пишите в комментариях 👇

Теперь и на хабре ✅

Написал свою первую статью на хабре

Рассказываю, почему ни один программист не может знать всё, как оценивают сроки задач в IT и какой язык программирования обрабатывает 90% всех банковских транзакций в мире.

Если интересно, приходите читать

p.s. Если статья зашла и у вас есть аккаунт на хабре, не откажусь от плюсика в карму аккаунта и к самой статье

➡️Как использовать HashMap и отстрелить себе ногу

На одном из собеседований по Java мне задали вопрос, проверяющий знания о внутреннем устройстве класса HashMap.

Сама задача и мои ответы ниже, а если у тебя есть еще варианты, пиши в комменты ☁️

Есть код

final var key = new KeyClass("Name", 123);
final var value = "some text";
final var map = new HashMap<KeyClass, String>();

map.put(key, value); //Добавляем пару ключ-значение в мапу

//some code

assert value.equals(map.get(key)); //выбросит ошибку, если условие будет false

В каких случаях в последней строке возникнет ошибка, или проще говоря, в каких случаях мы не найдем ожидаемого значения под ключом в HashMap?

▶️Вариант 1 - Easy
Просто поменяем значение под этим ключом

▶️Вариант 2 - Random
В классе KeyClass реализуем функцию hashCode() так, чтобы она возвращался разные значения, для одного и того же объекта, например пусть возвращает случайное число.

Тогда при поиске значения по ключу мы, скорее всего, получим неверный бакет, и не найдем в нем нужную пару ключ/значение.

А даже если мы попадем в нужный бакет, мы сравним хэши объектов, и, если они не совпадут, также не получим нужное значение.

▶️Вариант 3 - Mutable
Сделаем KeyClass мутабельным. Судя по конструктору в условии, в этом классе есть два поля, строковое и числовое.

Пусть equals и hashCode определены корректно и зависят от значения этих полей. Тогда, если мы можем изменить эти поля после записи пары key/value, то, из-за особенностей работы HashMap мы больше не сможем получить это значение по ключу.

▶️Вариант 4 - Lie
Реализуем equals у класса KeyClass так, чтобы метод всегда вовзращал false.
После этого мы снова не сможем получить значение из мапы по ключу.

🛠 Как можно нагрузить приложение? OLAP vs OLTP

Когда в вакансии пишут «опыт работы с высоконагруженными приложениями», что это значит? Это про миллионы запросов в секунду, как у соцсетей, или про сложные аналитические вычисления, как у систем отчетности?

На самом деле, здесь речь может идти о двух совершенно разных типах нагрузки: OLTP и OLAP.
Разберемся, чем они отличаются.


ℹ️ OLTP (Online Transaction Processing)
Это транзакционная нагрузка. То, о чем думают большинство людей, когда слышат словосочетание "высоконагруженное приложение".

Такая нагрузка подразумевает очень много не сложных операций.
На примере соц. сетей это могут быть - получение ленты подписок, получение всех диалогов пользователя, получение списка друзей, списка комментариев к записи, и так далее.

Выполнить одну такую операцию очень просто, но поддерживать доступность сервиса, когда таких запросов десятки тысяч в секунду - уже сложная задача.

Здесь пригодится знание кэшей, шардирования БД и скейлинга stateless сервисов.

🚛 OLAP (Online Analytical Processing)
Аналитическая нагрузка - полная противоположность. Самих операций очень мало, вплоть до 2-3 запросов в день, но сами запросы очень тяжелые.
Пример такой операции - анализ трат клиентов, выявление трендов, поиск по каким-то условиям, агрегация большого объема данных, прогноз спроса на товары на основе истории продаж за последние 5 лет.

Если OLTP запросы выполняются практически мгновенно, обработка OLAP запросов может занимать часы. В таком случае обычно используют асинхронный алгоритм.

Пользователь получает в ответ не результат, а id операции, которая запланирована к выполнению. С помощью этого id он может узнать статус операции, а когда выполнение закончится, получить итоговый результат.

Для такой нагрузки также стоит хорошо знать виды баз данных, партиционирование и шардинг, а также умение разбивать большую задачу на множество подзадач, которые можно выполнять независимо, а потом обрабатывать их результаты. Один из алгоритмов, которые можно применять - Map/Reduce.

Map/Reduce — это подход, который позволяет разбивать сложные задачи на более простые шаги: сначала обработка данных (Map), затем их объединение (Reduce). Такой подход активно используется в системах вроде Hadoop или Spark.

Вчера вышло новое видео про паттерн Transactional Outbox

Если готовишься к собесам на middle/senior бэкенд или просто нравится архитектура - must have к просмотру

Смотреть на YouTube 📹
Смотреть на Boosty (Без VPN) 💳