Backend

🤔 В чем разница между MVC и MVVM? Это две архитектурные паттерны, которые используются для разделения ответственности и улучшения структуры кода в приложениях. Несмотря на схожие цели, они имеют разные подходы к организации кода и взаимодействию компонентов. 🚩MVC (Model-View-Controller) 🟠Model (Модель) Представляет данные и бизнес-логику. Модель отвечает за получение данных из базы данных, выполнение операций над ними и отправку обновлений обратно в представление через контроллер. 🟠View (Представление) Отображает данные пользователю. Представление отвечает за визуальное представление данных, полученных от модели, и обновление интерфейса в ответ на изменения данных. 🟠Controller (Контроллер) Обрабатывает пользовательские вводы и взаимодействует с моделью и представлением. Контроллер получает ввод от пользователя, обрабатывает его (например, валидирует данные), обновляет модель и выбирает соответствующее представление для отображения. Пользователь взаимодействует с представлением (например, нажимает кнопку). Контроллер обрабатывает это событие, изменяет данные в модели. Модель уведомляет представление об изменениях. Представление обновляет отображение данных для пользователя. 🚩MVVM (Model-View-ViewModel) 🟠Model (Модель) Так же, как и в MVC, модель представляет данные и бизнес-логику. Модель не изменяется. 🟠View (Представление) Отвечает за визуальное представление данных. В отличие от MVC, представление связывается с ViewModel, а не с контроллером. 🟠ViewModel (Модель представления) Посредник между моделью и представлением. ViewModel содержит логику отображения и команду для представления. Он отвечает за преобразование данных из модели в форму, удобную для представления, и наоборот. ViewModel часто использует механизмы связывания данных (data binding) для автоматического обновления представления при изменении данных. Представление связывается с ViewModel через механизмы привязки данных. Пользователь взаимодействует с представлением (например, вводит текст). ViewModel обновляет данные в модели. Модель уведомляет ViewModel об изменениях. ViewModel автоматически обновляет представление через привязку данных. 🚩Основные различия 🟠Связывание данных В MVVM используется двустороннее связывание данных между представлением и ViewModel, что упрощает автоматическое обновление UI. В MVC такого механизма нет, и обновление представления осуществляется через контроллер. 🟠Посредник В MVC контроллер действует как посредник между моделью и представлением. В MVVM эту роль выполняет ViewModel, который теснее интегрирован с представлением через привязку данных. 🟠Упрощение UI-логики MVVM лучше подходит для сложных UI, так как позволяет выносить логику отображения в ViewModel, что делает код представления (UI) более чистым и простым. В MVC логика может оставаться в представлении или контроллере, что иногда усложняет структуру. 🟠Технологическая направленность MVVM часто используется в приложениях, где активно применяется привязка данных, например, в WPF, Xamarin, Angular. MVC более универсален и часто используется в веб-приложениях (например, ASP.NET MVC). Ставь 👍 и забирай 📚 Базу знаний

🤔Как определить, что у кода плохая организация? Плохая организация кода — это один из главных факторов, который делает поддержку и развитие проекта сложными. Определить, что код плохо организован, можно по следующим признакам: 🟠Отсутствие структуры - Файлы и каталоги разбросаны хаотично. - Код находится в одном огромном файле без логического разделения. - Нет четкой модулярности (всё смешано в одном месте). 🟠Дублирование кода - Один и тот же фрагмент кода повторяется в разных местах вместо вынесения в отдельные функции или классы. - При внесении изменений приходится исправлять одну и ту же логику в нескольких местах. 🟠Чрезмерная сложность - Функции или методы слишком длинные и делают слишком много. - Код трудно читать из-за вложенных конструкций (if, for, while и т. д.). - Используются сложные алгоритмы там, где можно было бы обойтись более простыми. 🟠Нарушение принципов SOLID - Один класс выполняет несколько задач (нарушение *Single Responsibility Principle*). - Сильная зависимость между модулями (нарушение *Dependency Inversion Principle*). - Проблемы с расширяемостью кода. 🟠Плохие наименования переменных, функций и классов - Используются непонятные или слишком короткие названия (a, x1, doSomething). - Название не отражает суть выполняемой операции. 🟠Отсутствие или избыточная документация - Если документации нет, код сложно понять. - Если документации слишком много, и она не актуальна, это также мешает. 🟠Сильная связанность (high coupling) - Компоненты сильно зависят друг от друга, что усложняет тестирование и внесение изменений. - Модули не могут использоваться независимо. 🟠Отсутствие тестов - Если код сложно протестировать, это признак плохой организации. - Нет юнит-тестов или они покрывают только тривиальные случаи. 🟠Отсутствие обработчиков ошибок - Ошибки не логируются, а просто подавляются (try...catch с пустым catch). - Ошибки обрабатываются хаотично. 🟠Проблемы с производительностью - Избыточное потребление памяти или процессорных ресурсов из-за неоптимальных алгоритмов. - Использование ненужных циклов, повторные вызовы функций. Ставь 👍 и забирай 📚 Базу знаний

🤔 Почему NULL часто называют «Ошибкой на миллиард долларов»? Термин «Ошибка на миллиард долларов» (The Billion Dollar Mistake) был введён Тони Хоаром (Tony Hoare), создателем NULL, который в 2009 году на конференции признался, что введение NULL было его крупнейшей ошибкой. Название связано с тем, что NULL стал причиной множества багов, сбоев в программах и уязвимостей, что привело к огромным финансовым потерям в индустрии. 🚩Какие проблемы вызывает `NULL`? 🟠NullPointerException (NPE) и аварийные сбои - Попытка вызвать метод у NULL приводит к ошибке NullPointerException в Java, NullReferenceException в C# и аналогичным сбоям в других языках. - Это одна из самых распространённых ошибок в программировании. 🟠Дополнительные проверки и сложность кода - Из-за NULL приходится постоянно писать проверки if (x != null), что раздувает код и делает его менее читаемым. - Если забыть такую проверку, можно получить неожиданный сбой. 🟠Слабая типизация и отсутствие явности - NULL можно передавать в любую функцию или объект, что ломает строгую типизацию. - Код становится менее предсказуемым. 🟠Проблемы с базами данных - NULL в SQL ведёт себя неинтуитивно (NULL != NULL, сравнение может давать UNKNOWN). - Может приводить к некорректным вычислениям в агрегатных функциях. 🟠Уязвимости в безопасности - Некоторые атаки используют NULL для взлома систем (например, null dereference в C/C++ может привести к DoS-атаке). - NULL может скрывать ошибки и приводить к утечке данных. 🚩Какие альтернативы `NULL`? 🟠Optional / Maybe (Java, Kotlin, Haskell, Rust) - Использование обёрток вроде Optional<T> (Java) или Option<T> (Rust) позволяет явно указывать возможность отсутствия значения. 🟠Исключения вместо `NULL` (C# и Java) - Вместо возврата NULL можно выбрасывать осмысленные исключения (IllegalArgumentException, NotFoundException). 🟠Специальные значения по умолчанию - Вместо NULL можно использовать дефолтные объекты (EmptyList, GuestUser и т. д.). 🟠Типы-юнит (Tagged Union) в функциональных языках - Например, в Haskell и Rust применяют Either<T, E>, Option<T>, что делает обработку NULL-подобных случаев более явной. Ставь 👍 и забирай 📚 Базу знаний

🤔 Чем отличаются LEFT JOIN от INNER JOIN? Это два типа соединений (joins) в языке SQL, которые используются для объединения строк из двух или более таблиц на основе связанных столбцов. Основное различие между ними заключается в том, какие строки включаются в результирующий набор данных. 🚩INNER JOIN Возвращает только те строки, которые имеют совпадающие значения в обеих таблицах, участвующих в соединении. Возвращает строки, где существует совпадение значений в обоих таблицах. Если нет совпадающих значений, строка не будет включена в результирующий набор.

    
        SELECT Employees.name, Departments.department_name
FROM Employees
INNER JOIN Departments ON Employees.department_id = Departments.id;{}
    

🚩LEFT JOIN Возвращает все строки из левой таблицы (первой таблицы в запросе) и соответствующие строки из правой таблицы. Если в правой таблице нет совпадающих строк, в результирующем наборе будут NULL значения для столбцов правой таблицы. Возвращает все строки из левой таблицы и соответствующие строки из правой таблицы. Если в правой таблице нет соответствия, возвращаются NULL значения для правой таблицы.

    
        SELECT Employees.name, Departments.department_name
FROM Employees
LEFT JOIN Departments ON Employees.department_id = Departments.id;{}
    

🚩Сравнение 🟠INNER JOIN Возвращает только совпадающие строки. Если нет совпадений, строки не включаются в результат. 🟠LEFT JOIN Возвращает все строки из левой таблицы. Включает совпадающие строки из правой таблицы. Если нет совпадений, строки из правой таблицы будут заполнены NULL значениями. Ставь 👍 и забирай 📚 Базу знаний

🤔 Как узнать свободное место на диске в консоли Linux? В Linux есть несколько команд для проверки свободного места на диске. 🟠`df` — информация о дисках Эта команда отображает информацию о файловых системах, включая общий объём, использованное и свободное пространство.

    
          df -h
  {}
    

Чтобы посмотреть только свободное место на корневом (/) разделе:

    
        df -h /{}
    

Если нужно узнать место на конкретном диске или разделе:

    
        df -h /dev/sda1{}
    

🟠`du` — информация об использовании места каталогом Команда du показывает, сколько места занимает конкретная директория

    
        du -sh /путь/к/папке{}
    

lsblk — информация о дисках и разделах

    
        lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT{}
    

🟠`fdisk` и `parted` — детальная информация о разделах Если нужно увидеть структуру разделов диска

    
        sudo fdisk -l{}
    

или

    
        sudo parted -l{}
    

🟠`ncdu` — удобный просмотр занятого пространства Если du неудобен, можно установить и использовать ncdu:

    
        sudo apt install ncdu  # Для Debian/Ubuntu
sudo yum install ncdu  # Для CentOS/RHEL
ncdu{}
    

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

🤔 Когда ROC AUC будет плохо определять качество классификатора ? ROC AUC (Receiver Operating Characteristic - Area Under Curve) является популярной метрикой для оценки качества бинарного классификатора. Однако, в некоторых ситуациях использование ROC AUC может быть неэффективным или вводящим в заблуждение. 🟠Сильно несбалансированные данные При сильном дисбалансе классов, где один класс существенно преобладает над другим, ROC AUC может давать завышенные оценки качества модели. Это происходит потому, что ROC AUC учитывает как истинно положительные, так и ложно положительные сработки, но при этом не всегда отражает способность модели предсказывать редкий класс. 🟠Различная стоимость ошибок Если ошибки различных типов (ложно положительные и ложно отрицательные) имеют разную стоимость, ROC AUC может неадекватно отражать качество модели. В таких случаях более подходящей метрикой может быть Precision-Recall Curve или специфическая метрика, учитывающая стоимость ошибок. 🟠Малое количество положительных примеров При малом количестве положительных примеров (класса 1), ROC AUC может стать менее надежной, так как небольшое изменение в предсказаниях может существенно повлиять на значение метрики. В таких случаях Precision-Recall Curve и PR AUC могут предоставить более надежную оценку. 🟠Нестабильность при малых выборках Может быть нестабильной и сильно зависеть от конкретного набора данных, особенно при небольших выборках. Это может привести к значительным колебаниям в оценках качества модели.

    
        import numpy as np
import pandas as pd
from sklearn.datasets import make_classification
from sklearn.model_selection import train_test_split
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import roc_auc_score, precision_recall_curve, auc

# Создание несбалансированного набора данных
X, y = make_classification(n_samples=1000, n_features=20, n_informative=2, n_redundant=10,
                           n_clusters_per_class=1, weights=[0.99], flip_y=0, random_state=42)

# Разделение на обучающую и тестовую выборки
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

# Обучение модели логистической регрессии
model = LogisticRegression()
model.fit(X_train, y_train)

# Предсказание вероятностей
y_scores = model.predict_proba(X_test)[:, 1]

# Вычисление ROC AUC
roc_auc = roc_auc_score(y_test, y_scores)

# Вычисление Precision-Recall AUC
precision, recall, _ = precision_recall_curve(y_test, y_scores)
pr_auc = auc(recall, precision)

print(f"ROC AUC: {roc_auc}")
print(f"Precision-Recall AUC: {pr_auc}"){}
    

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

Ваша история в IT начинается в Авито 🚀 Хотите расти в разработке — приходите на оплачиваемую стажировку в Авито. Мы ищем будущих специалистов в направлениях Frontend, Backend, QA и Android. Вы будете работать над продуктами, которыми ежедневно пользуются миллионы людей, и прокачивать навыки с помощью: ➡️ наставника — подскажет, как мыслить в процессе решения задач; ➡️ комьюнити стажёров — всегда рядом, чтобы обсудить задачи и поддержать; ➡️ корпоративных курсов, библиотек и баз знаний — всё, чтобы развиваться быстрее. Выберите два направления — основное и запасное. Если не получится попасть в первое, сможете пройти отбор на второе при наличии мест. Условия: ➡️ зарплата и корпоративный ноутбук, ➡️ формат — офис, удалёнка или гибрид, ➡️ от 25 часов в неделю, ➡️ продолжительность — 9 месяцев, ➡️ компенсация питания, консультации с психологами и юристами, ➡️ после стажировки — возможность остаться в команде, если покажите крутой результат. 📌 Регистрация открыта до 12 ноября. Подать заявку можно по ссылке.

🤔 Что такое миксины? Это один из способов повторного использования кода в объектно-ориентированном программировании. Они представляют собой классы или функции, которые предоставляют методы для других классов, без необходимости быть основой для этих классов. Миксины позволяют «подмешивать» функциональность в другие классы, обеспечивая гибкость и модульность кода. 🚩Характеристики 🟠Повторное использование кода Миксины позволяют избежать дублирования кода путем инкапсуляции общих методов и свойств, которые могут быть использованы в различных классах. 🟠Множественное наследование В языках, поддерживающих множественное наследование (например, Python), миксины могут быть использованы как базовые классы для других классов, предоставляя дополнительные методы и свойства. Это позволяет создавать классы, комбинируя несколько миксинов для расширения функциональности. 🟠Композиция В языках, где множественное наследование не поддерживается или нежелательно (например, в JavaScript), миксины могут быть применены через композицию, где функциональность миксина добавляется к целевому объекту или классу. 🟠Изоляция поведения Миксины позволяют изолировать и инкапсулировать определенное поведение или функциональность, что упрощает тестирование и поддержку кода. 🚩Примеры использования 🟠Python Миксины часто используются через множественное наследование.

    
        class LoggableMixin:
    def log(self, message):
        print(f"Log: {message}")

class Database(LoggableMixin):
    def save(self, data):
        self.log("Saving data")
        # Код для сохранения данных

db = Database()
db.save({"key": "value"}){}
    

🟠JavaScript Миксины могут быть применены через композицию.

    
        const loggableMixin = {
    log(message) {
        console.log(`Log: ${message}`);
    }
};

class Database {
    save(data) {
        this.log("Saving data");
        // Код для сохранения данных
    }
}

Object.assign(Database.prototype, loggableMixin);

const db = new Database();
db.save({ key: 'value' });{}
    

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

🤔 **Чем отличается rebase от merge?** В Git команды `rebase` и `merge` используются для объединения изменений из разных веток, но делают это по-разному. Основное различие между ними заключается в том, как они сохраняют историю коммитов и как они влияют на структуру репозитория. 🚩**Основные отличия** 🟠**Merge (Слияние)** Объединяет две ветки, создавая новый коммит слияния (merge commit), который имеет две родительских ветки. Сохраняет всю историю коммитов обеих веток без изменений. История ветвления и слияния сохраняется. Если есть конфликты, Git предложит их разрешить перед созданием коммита слияния. `git merge ` ```git checkout main git merge feature-branch``` 🟠**Rebase (Перебазирование)** Переносит все коммиты текущей ветки на вершину целевой ветки. Это делает историю линейной, как если бы изменения были сделаны последовательно. Изменяет историю коммитов, создавая новые коммиты для каждого коммита из текущей ветки. История ветвления исчезает. Если есть конфликты, Git предложит их разрешить по мере переноса каждого коммита. `git rebase ` ```git checkout feature-branch git rebase main``` 🚩**Плюсы** **и минусы** **🟠****Merge** ➕**Простота** Процесс слияния прост и понятен. ➕**Сохранение истории** Вся история коммитов сохраняется, включая информацию о ветвлении и слиянии. ➖**Коммиты слияния** Создаются дополнительные коммиты слияния, что может усложнить историю. 🟠**Rebase** ➕**Чистая история** История линейная и более читабельная. ➕**Упрощение навигации** Проще следить за последовательностью изменений. ➖**Изменение истории** Изменение коммитов может привести к проблемам, если кто-то уже основывается на этих коммитах. ➖**Конфликты** Может потребоваться больше усилий для разрешения конфликтов, особенно если коммитов много. 🚩**Когда использовать** 🟠**Merge** Когда важно сохранить полную историю изменений, включая ветвление и слияние. В крупных командных проектах, где история изменений важна для отслеживания. 🟠**Rebase** Когда важно иметь чистую и линейную историю изменений. Для интеграции изменений из основной ветки в текущую рабочую ветку перед отправкой изменений в основную ветку. **Ставь **[**👍**](https://t.me/eo_test_task_bot)** и забирай **[**📚 **](https://t.me/eo_test_task_bot)[**Базу знаний**](https://t.me/easy_backend/13)

🤔 В чём разница между сцеплением и связанностью? Это два ключевых свойства модульной архитектуры программного обеспечения, которые помогают оценить качество кода и архитектурных решений. 🚩Отличия 🟠Сцепление (Coupling) Описывает степень зависимости одного модуля от других. Высокое сцепление означает, что модули сильно зависят друг от друга, что затрудняет их изменение, тестирование и повторное использование, так как изменения в одном модуле требуют изменений в зависимых модулях. Идеально стремиться к слабому сцеплению, чтобы модули были максимально независимыми. Это позволяет изменять или заменять один модуль без необходимости изменения других. 🟠Связанность (Cohesion) Описывает, насколько тесно связанные и объединённые общей задачей элементы внутри одного модуля. Высокая связанность означает, что все функции и данные модуля логически связаны и выполняют одну задачу. Это упрощает понимание кода и делает модуль более автономным.Высокая связанность считается хорошей практикой, так как модуль с высокой связанностью проще в обслуживании, его легче изменить или заменить. 🚩Пример Представьте модуль, который управляет пользователями: если в модуле только функции для работы с пользователями (например, добавление и удаление), он обладает высокой связанностью, так как его функции направлены на одну задачу. Если модуль при этом минимально зависит от других частей системы, это говорит о слабом сцеплении. 🚩 Сравнение 🟠Слабое сцепление и высокая связанность Это желательные качества. Они помогают создать более гибкую и поддерживаемую систему. 🟠Сцепление Лучше, когда оно слабое, так как снижает зависимость между модулями. 🟠Связанность Лучше, когда она высокая, так как все функции модуля работают на достижение одной цели. Ставь 👍 и забирай 📚 Базу знаний