Backend

🤔 Чем отличается rebase от merge? В Git команды rebase и merge используются для объединения изменений из разных веток, но делают это по-разному. Основное различие между ними заключается в том, как они сохраняют историю коммитов и как они влияют на структуру репозитория. 🚩Основные отличия 🟠Merge (Слияние) Объединяет две ветки, создавая новый коммит слияния (merge commit), который имеет две родительских ветки. Сохраняет всю историю коммитов обеих веток без изменений. История ветвления и слияния сохраняется. Если есть конфликты, Git предложит их разрешить перед созданием коммита слияния. git merge <branch>

    
        git checkout main
git merge feature-branch{}
    

🟠Rebase (Перебазирование) Переносит все коммиты текущей ветки на вершину целевой ветки. Это делает историю линейной, как если бы изменения были сделаны последовательно. Изменяет историю коммитов, создавая новые коммиты для каждого коммита из текущей ветки. История ветвления исчезает. Если есть конфликты, Git предложит их разрешить по мере переноса каждого коммита. git rebase <branch>

    
        git checkout feature-branch
git rebase main{}
    

🚩Плюсы и минусы 🟠Merge ➕Простота Процесс слияния прост и понятен. ➕Сохранение истории Вся история коммитов сохраняется, включая информацию о ветвлении и слиянии. ➖Коммиты слияния Создаются дополнительные коммиты слияния, что может усложнить историю. 🟠Rebase ➕Чистая история История линейная и более читабельная. ➕Упрощение навигации Проще следить за последовательностью изменений. ➖Изменение истории Изменение коммитов может привести к проблемам, если кто-то уже основывается на этих коммитах. ➖Конфликты Может потребоваться больше усилий для разрешения конфликтов, особенно если коммитов много. 🚩Когда использовать 🟠Merge Когда важно сохранить полную историю изменений, включая ветвление и слияние. В крупных командных проектах, где история изменений важна для отслеживания. 🟠Rebase Когда важно иметь чистую и линейную историю изменений. Для интеграции изменений из основной ветки в текущую рабочую ветку перед отправкой изменений в основную ветку. Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое BigO notation? Big O notation (О-большое) - это математическая нотация, используемая в информатике для описания производительности алгоритма. Она выражает, как время выполнения или потребление памяти алгоритма растет по мере увеличения размера входных данных. Big O notation фокусируется на худшем случае, что помогает оценить наихудший сценарий для работы алгоритма. 🚩Основные концепции Big O notation 🟠Асимптотический анализ: Big O notation используется для описания асимптотического поведения алгоритмов, то есть их поведения при приближении размера входных данных к бесконечности. Основное внимание уделяется ведущим слагаемым и игнорированию констант и менее значимых слагаемых, поскольку они имеют меньшее влияние на производительность при больших размерах входных данных. 🟠Оценка худшего случая: Big O notation показывает наихудший возможный сценарий выполнения алгоритма, обеспечивая надежные гарантии его производительности. 🚩Основные классы сложности 🟠O(1) - Константная сложность: Время выполнения не зависит от размера входных данных. Доступ к элементу массива по индексу. 🟠O(log n) - Логарифмическая сложность: Время выполнения увеличивается логарифмически с увеличением размера входных данных. Бинарный поиск. 🟠O(n) - Линейная сложность: Время выполнения растет линейно с увеличением размера входных данных. Линейный поиск. 🟠O(n log n) - Линейно-логарифмическая сложность: Время выполнения растет линейно с логарифмическим множителем. Быстрая сортировка, сортировка слиянием. 🟠 O(n^2) - Квадратичная сложность: Время выполнения растет пропорционально квадрату размера входных данных. Сортировка пузырьком, сортировка вставками. 🟠O(2^n) - Экспоненциальная сложность: Время выполнения удваивается с каждым добавлением нового элемента. Решение задачи о коммивояжере полным перебором. 🟠O(n!) - Факториальная сложность: Время выполнения растет факториально с увеличением размера входных данных. Полный перебор всех возможных перестановок. 🚩Примеры использования 1⃣Поиск и сортировка: Анализ эффективности различных алгоритмов сортировки (например, быстрая сортировка vs. сортировка пузырьком). 2⃣Анализ алгоритмов и структур данных: Оценка времени доступа, вставки и удаления в различных структурах данных (например, массивы, списки, деревья). 3⃣Оптимизация программ: Помощь в выборе наиболее эффективных алгоритмов и структур данных для решения конкретных задач. Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие http методы могут быть? HTTP (HyperText Transfer Protocol) методы представляют собой набор стандартных операций, которые используются для взаимодействия между клиентом и сервером в сети. Каждый метод определяет конкретное действие, которое должен выполнить сервер. Вот основные HTTP методы и их предназначение: 🟠GET Метод GET используется для получения данных с сервера. Он запрашивает представление ресурса, не изменяя его состояния. GET запросы часто используются для запросов веб-страниц и получения данных из API. 🟠POST Метод POST используется для отправки данных на сервер с целью создания или обновления ресурса. Это может включать отправку формы на веб-сайте или загрузку файла. POST запросы обычно содержат данные в теле запроса. 🟠PUT Метод PUT используется для обновления существующего ресурса или создания нового ресурса на сервере. Если ресурс уже существует, он будет обновлен, если нет — будет создан. 🟠DELETE Метод DELETE используется для удаления ресурса с сервера. Запросы DELETE могут быть небезопасными, так как они изменяют состояние сервера, удаляя данные. 🟠PATCH Метод PATCH используется для частичного обновления ресурса. В отличие от PUT, который заменяет весь ресурс, PATCH изменяет только указанные части ресурса. 🟠HEAD Метод HEAD аналогичен GET, но без тела ответа. Используется для получения метаданных о ресурсе, таких как заголовки, без загрузки самого ресурса. 🟠OPTIONS Метод OPTIONS используется для запроса информации о поддерживаемых методах на сервере или на конкретном ресурсе. Это может быть полезно для определения доступных операций перед отправкой основного запроса. 🟠CONNECT Метод CONNECT используется для установления туннеля к серверу через прокси. Обычно используется для HTTPS через прокси. 🟠TRACE Метод TRACE выполняет тестовый запрос по маршруту до ресурса. Он возвращает запрос, полученный сервером, что может помочь в диагностике сетевых проблем или выявлении изменений в маршруте запроса. Ставь 👍 и забирай 📚 Базу знаний

🤔 Как можно заблокировать конкретные поля в Postgres? В PostgreSQL можно использовать различные методы для блокировки конкретных полей или строк таблицы, чтобы предотвратить их изменение или обеспечить управление конкурентным доступом к данным. Наиболее распространенные способы включают использование транзакционных блокировок и политик доступа. 🟠Использование блокировок уровня строки (Row-Level Locks) PostgreSQL поддерживает блокировки уровня строки с помощью команд SELECT FOR UPDATE и SELECT FOR SHARE. Эти команды позволяют заблокировать конкретные строки для изменения другими транзакциями, пока текущая транзакция не завершится.SELECT FOR UPDATE:

    
        BEGIN;  -- Начало транзакции

-- Выбираем и блокируем строки для обновления
SELECT * FROM my_table WHERE id = 1 FOR UPDATE;

-- Выполняем необходимые операции
UPDATE my_table SET field = 'new_value' WHERE id = 1;

COMMIT;  -- Завершение транзакции{}
    

SELECT FOR SHARE:

    
        BEGIN;  -- Начало транзакции

-- Выбираем и блокируем строки для чтения
SELECT * FROM my_table WHERE id = 1 FOR SHARE;

-- Выполняем необходимые операции
-- Изменение данных будет заблокировано для других транзакций
-- Однако, можно выполнять SELECT
COMMIT;  -- Завершение транзакции{}
    

🟠Использование политик доступа (Row-Level Security Policies) Политики безопасности на уровне строк позволяют определить, кто и при каких условиях может видеть или изменять данные в таблице. Это обеспечивается с помощью функций и политик безопасности.

    
        -- Включаем безопасность на уровне строк для таблицы
ALTER TABLE my_table ENABLE ROW LEVEL SECURITY;

-- Создаем роль, которая будет иметь доступ
CREATE ROLE limited_role;

-- Создаем политику, которая позволяет только чтение данных
CREATE POLICY read_only_policy ON my_table
    FOR SELECT
    USING (true);  -- Условие для выполнения SELECT

-- Применяем политику для роли limited_role
GRANT SELECT ON my_table TO limited_role;{}
    

🟠Использование триггеров (Triggers) Триггеры позволяют автоматически выполнять определенные действия перед или после операции INSERT, UPDATE, DELETE. Можно создать триггер, который будет блокировать изменение конкретных полей.

    
        CREATE OR REPLACE FUNCTION prevent_update()
RETURNS TRIGGER AS $$
BEGIN
    IF NEW.field IS DISTINCT FROM OLD.field THEN
        RAISE EXCEPTION 'Field "field" cannot be updated';
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- Применяем триггер к таблице
CREATE TRIGGER prevent_update_trigger
BEFORE UPDATE ON my_table
FOR EACH ROW
EXECUTE FUNCTION prevent_update();{}
    

🟠Ограничения на уровне столбца (Column-Level Constraints) Ограничения на уровне столбца могут использоваться для ограничения возможных значений или для создания выражений, которые должны быть выполнены для выполнения изменения.

    
        ALTER TABLE my_table
    ADD CONSTRAINT field_check CHECK (field IS NOT NULL);{}
    

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что в твоем понимании значит правильный код? Это код, который не только выполняет поставленные задачи, но и соответствует ряду критериев, обеспечивающих его качество, читаемость, сопровождение и эффективность. 🚩Характеристики 🟠Читаемость Переменные, функции, классы и другие сущности должны иметь понятные и описательные имена, которые отражают их назначение. Следование стандартам кодирования и стиля, включая правильное форматирование, отступы и использование комментариев. Использование комментариев для объяснения сложных или неочевидных частей кода, но не для очевидных вещей, которые можно понять из названий переменных и функций. 🟠Сопровождаемость Код должен быть разбит на модули, функции или классы с чётко определёнными задачами. Это упрощает его понимание, тестирование и изменение. Избегание дублирования кода через применение принципа DRY (Don't Repeat Yourself). Код должен быть легко тестируемым. Написание автоматических тестов для проверки корректности работы помогает предотвратить ошибки. 🟠Эффективность Код должен быть оптимизирован для выполнения задач с минимальными затратами ресурсов, таких как время выполнения и использование памяти. Использование эффективных алгоритмов и структур данных для обеспечения хорошей производительности, особенно на больших объемах данных. 🟠Надежность Код должен корректно обрабатывать ошибки и исключительные ситуации, предотвращая неожиданные сбои. Проверка входных данных для предотвращения некорректного поведения программы. 🟠Документированность Написание документации, описывающей основные компоненты системы, их взаимодействие и использование. Хорошо документированный код облегчает его понимание для других разработчиков. 🟠Применение принципов и паттернов проектирования Применение принципов SOLID для создания устойчивого, гибкого и масштабируемого кода. Использование проверенных решений для общих задач проектирования. 🚩Примеры Читаемость и сопровождаемость

    
        def calculate_area(radius):
    """Calculate the area of a circle given its radius."""
    import math
    if radius < 0:
        raise ValueError("Radius cannot be negative")
    return math.pi * radius ** 2{}
    

Тестируемость

    
        def add(a, b):
    """Add two numbers and return the result."""
    return a + b

# Unit test for the add function
def test_add():
    assert add(2, 3) == 5
    assert add(-1, 1) == 0
    assert add(0, 0) == 0

test_add(){}
    

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое SOLID? Это акроним, представляющий пять основных принципов объектно-ориентированного программирования и дизайна, которые помогают разработчикам создавать более понятный, гибкий и поддерживаемый код. Эти принципы были предложены Робертом Мартином (известным также как Uncle Bob) и являются основополагающими в области программной инженерии. 🟠Single Responsibility Principle (Принцип единственной ответственности) Этот принцип гласит, что у каждого класса должна быть только одна причина для изменения, то есть класс должен иметь только одну ответственность или задачу. Это помогает уменьшить сложность и повысить читаемость кода, делая его более управляемым и легким для поддержки. Когда класс выполняет лишь одну задачу, его легче тестировать и изменять без влияния на другие части системы. 🟠Open/Closed Principle (Принцип открытости/закрытости) Программные сущности (классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для модификации. Это означает, что поведение классов должно быть расширяемым без изменения их исходного кода. Для реализации этого принципа часто используются абстракции и интерфейсы, которые позволяют добавлять новые функции через наследование и полиморфизм, не нарушая существующий код. 🟠Liskov Substitution Principle (Принцип подстановки Барбары Лисков) Объекты подклассов должны быть заменяемы объектами суперклассов без нарушения правильности программы. Это означает, что если у нас есть базовый класс и его подкласс, то мы должны иметь возможность заменить экземпляры базового класса экземплярами подкласса без изменения желаемого поведения программы. Этот принцип поддерживает полиморфизм и гарантирует, что производные классы могут корректно взаимодействовать с остальным кодом. 🟠Interface Segregation Principle (Принцип разделения интерфейсов) Клиенты не должны зависеть от интерфейсов, которые они не используют. Этот принцип направлен на создание узкоспециализированных интерфейсов, которые являются специфичными для отдельных клиентов. Таким образом, классы, реализующие эти интерфейсы, не будут обязаны реализовывать методы, которые им не нужны. Это уменьшает сложность и улучшает управляемость кода, а также способствует гибкости и повторному использованию интерфейсов. 🟠Dependency Inversion Principle (Принцип инверсии зависимостей) Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба типа модулей должны зависеть от абстракций. Этот принцип направлен на уменьшение зависимости высокоуровневого кода от низкоуровневых деталей, что позволяет легче изменять и тестировать систему. Реализация этого принципа часто включает использование инверсии управления (IoC) и внедрения зависимостей (DI), что способствует созданию более гибких и модульных архитектур. Ставь 👍 и забирай 📚 Базу знаний

🤔 Что знаешь о принципах программирования KISS? Это принцип проектирования и разработки, который предполагает, что системы и решения должны быть максимально простыми и избегать ненужной сложности. Этот принцип особенно важен в программировании и инженерии, так как помогает создавать более понятные, поддерживаемые и надежные системы. 🚩Аспекты 🟠Простота Системы должны быть простыми в понимании и использовании. Чем проще система, тем меньше вероятность возникновения ошибок. Простота достигается за счет минимизации количества компонентов и взаимодействий между ними. 🟠Ясность Код должен быть понятным и легко читаемым. Это облегчает его поддержку и модификацию. Использование понятных имен переменных, функций и классов, а также понятная структура кода способствуют ясности. 🟠Избегание избыточности Компоненты или функциональность следует избегать. Если какой-то элемент системы не добавляет реальной ценности, его следует убрать. Это включает в себя как аппаратное, так и программное обеспечение. 🟠Модульность Системы должны быть разбиты на небольшие, независимые модули, каждый из которых выполняет свою четко определенную задачу. Модульность помогает в тестировании, повторном использовании и поддержке кода. 🚩Примеры применения 🟠Программирование При разработке функций или методов следует избегать создания слишком сложных алгоритмов, если можно использовать более простые и понятные решения. Использование стандартных библиотек и инструментов вместо написания собственного кода с нуля, когда это возможно. 🟠Проектирование систем В системной архитектуре следует избегать излишнего усложнения связей между компонентами системы. Использование простых и проверенных шаблонов проектирования вместо сложных и экспериментальных решений. 🟠Документация Документация должна быть простой и понятной, избегая излишне технических или сложных объяснений. Хорошо структурированная и лаконичная документация помогает пользователям и разработчикам быстрее понять систему. 🚩Плюсы ➕Легкость понимания и поддержки Простые системы легче понимать и поддерживать, что снижает затраты на обучение и поддержку. ➕Снижение количества ошибок Чем проще система, тем меньше вероятность возникновения ошибок и проблем при её использовании. ➕Повышение производительности Простые решения часто требуют меньше ресурсов и могут работать быстрее и эффективнее. ➕Улучшение масштабируемости Простые и модульные системы легче масштабировать и расширять по мере необходимости. Ставь 👍 и забирай 📚 Базу знаний

🤔 Какая разница у протоколов http и https ? Основное различие между протоколами HTTP (HyperText Transfer Protocol) и HTTPS (HyperText Transfer Protocol Secure) заключается в уровне безопасности, который они обеспечивают при передаче данных между клиентом (например, веб-браузером) и сервером. 🚩Основные различия 🟠Шифрование HTTP: Данные передаются в открытом виде, что делает их уязвимыми для перехвата и чтения злоумышленниками. HTTPS: Данные передаются в зашифрованном виде с использованием SSL/TLS (Secure Sockets Layer/Transport Layer Security). Это обеспечивает защиту данных от перехвата и несанкционированного доступа. 🟠Аутентификация HTTP: Отсутствует механизм аутентификации, что затрудняет проверку подлинности веб-сайта. HTTPS: Использует сертификаты SSL/TLS, которые удостоверяют подлинность веб-сайта, подтверждая, что соединение установлено с тем сервером, с которым намеревался связаться пользователь. 🟠Интегритет данных HTTP: Данные могут быть изменены или повреждены во время передачи, и это не будет обнаружено. HTTPS: Гарантирует целостность данных, так как любые изменения данных при передаче будут обнаружены, и соединение будет разорвано. 🟠Порт HTTP: Использует порт 80 по умолчанию. HTTPS: Использует порт 443 по умолчанию. 🚩Плюсы ➕Безопасность Обеспечивает защиту конфиденциальной информации, такой как логины, пароли, номера кредитных карт. ➕Доверие пользователей Пользователи склонны больше доверять веб-сайтам, использующим HTTPS, так как это указывает на то, что сайт заботится о безопасности данных. ➕SEO Поисковые системы, такие как Google, предпочитают сайты, использующие HTTPS, и ранжируют их выше по сравнению с сайтами, использующими HTTP. Ставь 👍 и забирай 📚 Базу знаний

🤔 Что знаешь о хеш функции? Хеш-функция — это функция, которая принимает входные данные (ключ) и возвращает фиксированное число, называемое хешем (или хеш-значением). Основная цель хеш-функции — преобразовать произвольные данные в числовое значение определенного диапазона. 🚩Основные свойства хеш-функции: 🟠 Детерминированность: Хеш-функция всегда должна возвращать одно и то же хеш-значение для одного и того же входного значения. 🟠Равномерное распределение: Хорошая хеш-функция должна равномерно распределять хеш-значения по всему диапазону, чтобы минимизировать количество коллизий. 🟠Быстрота вычисления: Хеш-функция должна быть достаточно быстрой, чтобы не замедлять общую производительность алгоритмов, которые её используют. 🟠Минимизация коллизий: Коллизия возникает, когда два разных входных значения дают одно и то же хеш-значение. Хорошая хеш-функция должна минимизировать вероятность таких случаев. 🚩Применение хеш-функций: 🟠Хеш-таблицы: Используются для вычисления индекса массива, где будет храниться значение, связанное с ключом. Это позволяет быстро выполнять операции вставки, удаления и поиска. 🟠Криптография: Криптографические хеш-функции (например, SHA-256, MD5) используются для обеспечения целостности данных, создания цифровых подписей и безопасного хранения паролей. 🟠Контроль целостности данных: Хеш-функции применяются для проверки целостности данных при передаче или хранении, позволяя выявлять ошибки или изменения в данных. 🟠Генерация уникальных идентификаторов: Хеш-функции используются для генерации уникальных идентификаторов (например, UUID), основываясь на входных данных. 🚩Примеры хеш-функций 🟠Простая хеш-функция: Эта функция возвращает остаток от деления длины ключа на размер таблицы. Она проста, но не обеспечивает равномерное распределение.

    
        def simple_hash(key, table_size):
    return len(key) % table_size{}
    

🟠Хеш-функция для строк (например, DJB2):

    
        def djb2_hash(key):
    hash_value = 5381
    for char in key:
        hash_value = ((hash_value << 5) + hash_value) + ord(char) # hash_value * 33 + ord(char)
    return hash_value{}
    

🚩Методы разрешения коллизий 🟠Метод цепочек (chaining): В каждой ячейке массива хранится список значений, которые хешируются в один и тот же индекс. 🟠Открытая адресация (open addressing): При коллизии ищется другая свободная ячейка по определённому алгоритму (например, линейное пробирование, квадратичное пробирование или двойное хеширование). Ставь 👍 и забирай 📚 Базу знаний

🤔 Логика предметной области в хранимых процедурах: плюсы и минусы Это исполняемый код (например, SQL-скрипты), который хранится и выполняется непосредственно в базе данных. Разработка бизнес-логики внутри хранимых процедур является спорной практикой. Она имеет как преимущества, так и недостатки в зависимости от требований системы, архитектуры и команды разработки. 🚩Плюсы ➕Повышение производительности Хранимые процедуры выполняются на сервере базы данных, что уменьшает накладные расходы на передачу данных между приложением и базой. Обработка больших объёмов данных становится быстрее, так как нет необходимости отправлять их в приложение и обратно. ➕Централизация бизнес-логики Вся логика предметной области сосредоточена в одном месте (в БД), что облегчает контроль доступа и выполнение важных операций. Удобно для многослойных систем, где несколько клиентских приложений используют одну базу данных. ➕Снижение нагрузки на сетевой канал Вместо передачи большого количества SQL-запросов между сервером базы данных и приложением, выполняется один вызов процедуры. ➕Повышение безопасности Системы могут ограничить доступ к таблицам и предоставить доступ только к хранимым процедурам, что снижает риск несанкционированного доступа. Встроенные механизмы контроля прав доступа (например, в PostgreSQL и Oracle). ➕Языковые возможности БД Современные СУБД поддерживают процедурные языки, такие как PL/pgSQL (PostgreSQL), T-SQL (SQL Server) или PL/SQL (Oracle), которые предоставляют функции, циклы и исключения, что позволяет реализовать сложную логику. ➕Миграция между системами При необходимости переноса части функциональности между разными приложениями (например, Web-приложением и мобильным клиентом) логика в БД остаётся неизменной. 🚩Минусы ➖Сложность поддержки и сопровождения Хранимые процедуры часто сложны для чтения, отладки и тестирования по сравнению с кодом на языке программирования (например, Java, C#, Python). Версионный контроль затруднён, так как БД не всегда удобно интегрируется с системами контроля версий (Git). ➖Жёсткая зависимость от БД Логика, написанная в хранимых процедурах, привязывает систему к конкретной СУБД (например, Oracle или SQL Server). Переход на другую БД становится дорогостоящим и трудоёмким. ➖Отсутствие масштабируемости Сервер базы данных становится "узким местом" системы. Если бизнес-логика выполняется только на сервере БД, это может привести к перегрузке, особенно при высоком трафике. ➖Ограниченные возможности тестирования Инструменты для юнит-тестирования и автоматизированного тестирования хранимых процедур менее развиты, чем для традиционного кода приложений. Тестирование бизнес-логики требует специальной инфраструктуры (например, отдельной тестовой БД). ➖Смешение слоёв архитектуры Внедрение логики в БД нарушает принципы многослойной архитектуры, такие как Separation of Concerns (разделение ответственности). Логика бизнес-уровня смешивается с уровнем данных. ➖Меньшая гибкость разработки Разработка и деплой изменений в хранимых процедурах требуют взаимодействия с базой данных, что замедляет процесс внедрения обновлений. Изменения в хранимых процедурах могут повлиять на производительность всей системы. ➖Зависимость от разработчиков БД Написание и оптимизация хранимых процедур требуют специфических навыков SQL и понимания особенностей СУБД. Не все разработчики владеют этими навыками. 🚩Когда стоит использовать? 🟠Производительность критична Если необходимо минимизировать сетевые вызовы и максимально эффективно обрабатывать большие объёмы данных. 🟠Централизация логики Если бизнес-логика должна быть единой для нескольких клиентов (например, мобильного приложения, веб-сервиса). 🟠Ограничение доступа Если безопасность и контроль доступа являются приоритетом. 🟠Проекты с жёсткой привязкой к БД Например, для старых систем или проектов, где миграция на новую архитектуру невозможна. Ставь 👍 и забирай 📚 Базу знаний