├── LICENSE ├── README.md ├── backend └── node.js │ ├── README.md │ ├── additional-resources.md │ ├── best-practices.md │ ├── cli-game │ ├── README.md │ └── script-example.md │ ├── currencies-bot │ └── README.md │ ├── dex-sniper-bot │ └── README.md │ ├── tasks-manager │ └── README.md │ └── voting-poll-system │ └── README.md ├── bad-indents-example.png ├── fontend-faq.md ├── frontend.md └── popular-issues.md /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2024 MetaLamp 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | + Backend 2 | * [haskell](https://github.com/fullstack-development/haskell-internship?tab=readme-ov-file) 3 | * [node.js](backend/node.js/README.md) 4 | + [Frontend](./frontend.md) 5 | + Solidity 6 | + Web3 Frontend 7 | -------------------------------------------------------------------------------- /backend/node.js/README.md: -------------------------------------------------------------------------------- 1 | # Добро пожаловать в программу обучения по Node.js 2 | 3 | В рамках программы вы поэтапно освоите ключевые концепции: работу с асинхронным кодом, создание серверных приложений, взаимодействие с базами данных, разработку ботов и работу с блокчейн-сетями. Программа открыта, бесплатна и не ограничена по срокам прохождения. 4 | 5 | Общение во время обучения проходит в Telegram-чате [MetaLamp Node.js Education](https://t.me/+6yG0kMySQi40YjUy), где вы можете взаимодействовать с другими участниками и задавать вопросы. 6 | 7 | По завершении программы, включая этап код-ревью, у вас будет возможность пройти интервью, получить сертификат об окончании и получить карьерную консультацию. 8 | 9 | ### Disclaimer по веб3 10 | 11 | В программе обучения есть [задание](dex-sniper-bot/README.md), которое сосредоточено на создании инфраструктуры и инструментов для взаимодействия с веб3-приложениями (в данном случае — снайпер-бота). Работа со смарт-контрактами, их разработка или анализ в рамках этого задания не предусмотрена. Если ваша цель — изучение разработки смарт-контрактов, обратите внимание на нашу отдельную программу, посвящённую [Solidity](https://github.com/fullstack-development/solidity-developer-roadmap/blob/main/junior-1/README.md). Для базового погружения в web3 тематику рекомендуем познакомиться с нашей картой развития: [Web3 roadmap for non-developers](https://github.com/fullstack-development/web3-roadmap). 12 | 13 | ### Структура курса 14 | 15 | Программа состоит из теоретического блока и пяти практических заданий, каждое из которых помогает освоить определенные технологии и шаблоны разработки. Шаг за шагом вы будете учиться применять различные подходы и инструменты. После прохождения всех этапов у вас будут как теоретические знания, так и практические навыки для создания современных приложений на Node.js. 16 | 17 | 1. Теоретический блок (3-4 недели) 18 | 19 | Теоретическая часть включает основы JavaScript, работу с типизацией в TypeScript, изучение Node.js и фреймворка Nest.js. Прежде чем приступать к выполнению заданий, рекомендуется ознакомиться со следующими материалами: 20 | 21 | * [Учебник JavaScript](https://learn.javascript.ru/) 22 | * [TypeScript Documentation](https://www.typescriptlang.org/docs/) 23 | * [Документация Node.js](https://nodejsdev.ru/guides/webdraftt/) 24 | 25 | Вы можете использовать любые другие материалы, которые помогут вам разобраться в теме. Кроме того, каждое практическое задание содержит список ресурсов для изучения перед началом работы. Ресурсы в заданиях не дублируются, но предполагается, что материалы из предыдущих этапов уже освоены. 26 | 27 | Также мы добавили раздел [дополнительных ресурсов](./additional-resources.md) со списком книг, не обязательных к изучению, но которые могут помочь разобраться, если что-то непонятно в основных источниках. 28 | 29 | 2. [CLI-текстовый квест на TypeScript](cli-game/README.md) (2-3 недели) 30 | 31 | Научитесь создавать простые текстовые игры с использованием паттерна MVC и объектно-ориентированного программирования. 32 | 33 | 3. [Телеграм-бот с асинхронными запросами](currencies-bot/README.md) (2-3 недели) 34 | 35 | Познакомитесь с асинхронными операциями и работой с API через HTTP-запросы, создавая телеграм-бот. 36 | 37 | 4. [Система управления задачами на Express](tasks-manager/README.md) (3-4 недели) 38 | 39 | Освоите базовые CRUD-операции и взаимодействие с базой данных на основе PostgreSQL с использованием фреймворка Express и ORM Prisma. 40 | 41 | 5. [Четвёртое задание: Система голосований](voting-poll-system/README.md) (3-4 недели) 42 | 43 | Разработаете платформу для создания и участия в опросах с использованием фреймворка Nest.js, а также попрактикуете работу с TypeORM. 44 | 45 | 6. [Sniper bot для Телеграма](dex-sniper-bot/README.md) (4-6 недель) 46 | 47 | Создайте снайпер-бота для автоматического мониторинга появления новых токенов, анализа цен и выполнения сделок на децентрализованных биржах. Развивайте навыки автоматизации и работы с веб3-экосистемой. 48 | 49 | 7. Самостоятельный рефакторинг (3-6 недель) 50 | 51 | Прежде чем отправить код на ревью специалистам Metalamp, проведите самостоятельный рефакторинг. Для этого воспользуйтесь списком [best practices](./best-practices.md), который включает наши стандарты и частые замечания, возникающие в процессе ревью. Самостоятельный рефакторинг подразумевает проверку своего кода на соответствие предложенным стандартам и внесение необходимых правок. Такой подход облегчит процесс ревью как для проверяющего, так и для вас, помогая избежать распространенных ошибок. 52 | 53 | Рефакторинг можно провести как после завершения всех заданий, так и после каждого из них. Рекомендуется также просматривать список best practices во время выполнения заданий — так вы сможете сразу учитывать требования при написании кода и упростите себе этап рефакторинга. 54 | 55 | 8. Код ревью (3-6 недель) 56 | 57 | После рефакторинга свяжитесь с менеджером программы в Telegram (@lana_dulceva), чтобы сообщить о готовности к ревью. Один из наших опытных разработчиков проведет проверку кода и оставит комментарии, которые нужно будет учесть и исправить. 58 | -------------------------------------------------------------------------------- /backend/node.js/additional-resources.md: -------------------------------------------------------------------------------- 1 | # Дополнительные ресурсы 2 | 3 | Дополнительные ресурсы могут помочь разобраться, если в основных источниках что-то непонятно. Их не обязательно изучать для прохождения курса, но иногда, при чтении сложной и непонятной темы в разных источниках, приходит озарение. :) 4 | 5 | ### Книги: 6 | 7 | 1. Дуглас Крокфорд - Javascript. Cильные стороны. 8 | 9 | 2. Борис Чёрный - Профессиональный Typescript. Разработка масштабируемых javаScript приложений. 10 | 11 | 3. Каскиаро Марио, Маммино Лучано - Шаблоны проектирования Node.JS. 12 | -------------------------------------------------------------------------------- /backend/node.js/best-practices.md: -------------------------------------------------------------------------------- 1 | # Требования к оформлению проекта 2 | 3 | ### Разбиение на модули 4 | 5 | Функциональность должна быть разбита на модули, объединенные по смыслу. Каждый модуль решает одну задачу и может быть легко переиспользован. 6 | 7 | ### Именование функций и переменных 8 | 9 | Названия функций должны четко отражать выполняемое действие, а переменные — содержимое. 10 | * Используйте глаголы для функций и существительные для переменных. 11 | * Не используйте аббревиатуры, за исключением общепринятых (например, id, API, URL). 12 | 13 | ### Принцип DRY (Don't Repeat Yourself) 14 | 15 | Не дублируйте код. Если один и тот же блок используется несколько раз, выделите его в отдельную функцию или модуль. 16 | 17 | ### Уровень вложенности 18 | 19 | Избегайте глубокой вложенности в условных операторах и операторах выбора: не более 2 уровней. 20 | 21 | ### Обработка ошибок 22 | 23 | Обрабатывайте ошибки таким образом, чтобы не только логировать их, но и возвращать пользователю понятные и информативные сообщения. 24 | 25 | ### Типизация 26 | 27 | Всегда задавайте типы для параметров и возвращаемых значений функций. Не используйте `any`, если этого можно избежать. Предпочитайте строгую типизацию и продуманное использование `unknown`. 28 | Используйте интерфейсы или типы для сложных объектов и структур данных. 29 | 30 | ### Консистентность в коде 31 | 32 | Следите за единообразием отступов, пробелов и других элементов форматирования. Используйте линтер ESLint и форматтер Prettier для поддержания консистентного стиля кода. 33 | 34 | ### REST API 35 | 36 | Соблюдайте конвенции REST при работе с эндпоинтами. 37 | В контроллерах Nest.js избегайте логики обработки данных; она должна находиться в сервисах. 38 | 39 | ### Форматирование и стилистика 40 | 41 | Для перечислений и булевых значений используйте понятные и полные слова (например, `isActive` вместо `act`). 42 | Логические значения не должны отрицаться более одного раза в выражении (`!isActive` вместо `!!isInactive`). 43 | 44 | ### Использование DTO (Data Transfer Object) 45 | 46 | Для передачи данных между слоями используйте DTO. Описание DTO позволяет лучше структурировать входные данные и следить за их корректностью. 47 | 48 | ### Работа с базами данных 49 | 50 | Используйте типы данных, подходящие для хранения нужной информации (например, `timestamp` для временных меток). 51 | Всегда валидируйте и фильтруйте данные, поступающие в базу данных, особенно для полей, которые могут вводиться пользователями. -------------------------------------------------------------------------------- /backend/node.js/cli-game/README.md: -------------------------------------------------------------------------------- 1 | # Первое задание: CLI текстовый квест 2 | 3 | Необходимо создать консольное приложение, которое реализует простой текстовый квест. Пользователь будет взаимодействовать с игрой через текстовые команды в терминале. 4 | 5 | ## Описание проекта 6 | 7 | **1. Начало игры:** 8 | 9 | Пользователь запускает скрипт, после чего игра выводит вступительный текст с описанием начальной ситуации и списком действий. 10 | 11 | **2. Выбор действий:** 12 | 13 | На каждом этапе пользователю предлагается выбор из нескольких действий. Например, могут быть такие действия: 14 | 15 | - Направо 16 | - Налево 17 | - Осмотреться (получить список всех предметов, с которыми можно взаимодействовать) 18 | 19 | **3. Реализация логики игры:** 20 | 21 | В зависимости от выбора пользователя, игра должна выводить различные текстовые описания и предоставлять новые выборы. Можно учесть несколько ветвлений сценария, чтобы пользователю было интересно исследовать разные пути. 22 | 23 | **4. Конец игры:** 24 | 25 | Игра может завершиться несколькими способами (например, победа, поражение или нейтральный конец). Важно, чтобы игра отслеживала статус пользователя и корректно завершала сессию. 26 | 27 | **Пример готового текстового квеста:** 28 | 29 | [Квест «Вампиры! (часть 1)»](https://apero.ru/%D0%A2%D0%B5%D0%BA%D1%81%D1%82%D0%BE%D0%B2%D1%8B%D0%B5-%D0%B8%D0%B3%D1%80%D1%8B/%D0%92%D0%B0%D0%BC%D0%BF%D0%B8%D1%80%D1%8B). Этот пример в веб формате, можно поиграть, чтобы получить представление о текстовых квестах. 30 | 31 | ## Требования 32 | 33 | 1. Код должен быть написан на TypeScript. Использовать фреймворки и внешние библиотеки не требуется. Разрешено использование только стандартных возможностей среды выполнения Node.js (например, для чтения/записи файлов, взаимодействия с консолью и выполнения скрипта). Основной упор сделайте на использование TypeScript для строгой типизации каждого этапа игры, чтобы структура оставалась понятной и легко поддерживалась. 34 | 35 | 2. Нужно использовать паттерн Model-View-Controller (MVC) и объектно-ориентированное пограммирование (ООП). 36 | 37 | 3. Каждое действие в игре должно быть представлено в виде объекта с описанием и результатом. Например, переходы между шагами игры должны быть легко управляемы через объекты. 38 | 39 | 4. Состояние игры не должно содержать информацию о конкретных сценариях. Вместо этого, используйте отдельные объекты для каждого сценария. Это обеспечит лёгкость в добавлении новых сценариев без значительных изменений кода. 40 | 41 | 5. Новые сценарии должны добавляться без необходимости вносить изменения в основную логику игры. Структура кода должна позволять просто подключать новые элементы или ветки. 42 | 43 | 6. Задание не требует сохранения прогресса или взаимодействия с базами данных. Однако ваш код должен быть спроектирован так, чтобы в будущем можно было легко добавить эти функции. 44 | 45 | 7. Нужно протестировать логику игры. 46 | 47 | 8. Файл README.md должен содержать краткое описание проекта и инструкцию по запуску и тестированию проекта. 48 | 49 | ## Сценарий 50 | 51 | К заданию прилагается сценарий игры ["Таинственный лес"](script-example.md). Можно полностью опираться на него или можно использовать его как пример для создания своего (небольшого) сценарий. 52 | 53 | ## Тестирование 54 | 55 | Нужно написать юнит тесты, чтобы убедиться в правильности логики работы игры. Основной функционал, который нужно протестировать: 56 | 57 | - Игра должна корректно изменять своё состояние в зависимости от действий игрока. 58 | 59 | **Пример:** Проверьте, что при выборе действия "Направо" состояние игры меняется с "Начало" на "Поворот направо". 60 | 61 | - Действия игрока должны выполняться корректно, возвращать правильное описание и вести к правильному следующему шагу. 62 | 63 | **Пример:** Создайте действие "Переход через мост" и проверьте, что его выполнение возвращает правильное сообщение и ведет к шагу "Конец". 64 | 65 | - Игра должна правильно отображать информацию для игрока, включая доступные действия и результаты их выполнения. 66 | 67 | **Пример:** Проверьте, что при выполнении действия "Перейти через мост" представление выводит сообщение "Мост обрушился под вами". 68 | 69 | - В случае ошибочного ввода от игрока игра должна отображать сообщение об ошибке и список доступных действий. 70 | 71 | **Пример:** Проверьте, что при некорректном выборе действия выводится сообщение об ошибке и разрешенные действия. 72 | 73 | ## Подсказки и ресурсы 74 | 75 | Для написания проекта могут понадобится следующие теоретические знания: 76 | 77 | **1. Паттерн MVC (Model-View-Controller):** 78 | 79 | Это основной паттерн, который применяется в проекте. Он разделяет приложение на три части: модель (состояние игры), представление (то, как информация показывается пользователю) и контроллер (логика обработки действий пользователя). Это упрощает сопровождение и расширение приложения. 80 | 81 | - [Архитектурный паттерн MVC](https://doka.guide/tools/architecture-mvc/) 82 | 83 | **2. Паттерн State (Состояние):** 84 | 85 | Игра управляется состоянием, которое хранит текущий шаг и сценарий. В зависимости от выбора действия игроком состояние игры изменяется, и это влияет на последующие действия. 86 | 87 | - [Состояние](https://refactoring.guru/ru/design-patterns/state) 88 | - [Состояние на TypeScript](https://refactoring.guru/ru/design-patterns/state/typescript/example) 89 | 90 | **3. Паттерн Command (Команда):** 91 | 92 | Каждое действие игрока в виде объектов можно рассматривать как реализацию паттерна Command. Эти действия представляют команды, которые игрок выполняет, и они инкапсулируют логику выполнения (например, переход на следующий шаг). 93 | 94 | - [Команда](https://refactoring.guru/ru/design-patterns/command) 95 | - [Команда на TypeScript](https://refactoring.guru/ru/design-patterns/command/typescript/example) 96 | -------------------------------------------------------------------------------- /backend/node.js/cli-game/script-example.md: -------------------------------------------------------------------------------- 1 | # Сценарий "Таинственный лес" 2 | 3 | ## Начало: 4 | 5 | Вы просыпаетесь в центре густого леса, окруженного туманом. Единственный звук, который вы слышите, — это ветер, шелестящий в листве деревьев. Перед вами две тропинки. Одна ведет направо, другая — налево. 6 | 7 | ### Действие 1 8 | 9 | - Направо 10 | - Налево 11 | 12 | ## Ветка 1: Направо 13 | 14 | Вы поворачиваете направо и идёте по узкой тропинке. Через некоторое время перед вами появляется старый мост, ведущий через бурную реку. 15 | 16 | ### Действие 2 17 | 18 | - Перейти через мост 19 | - Вернуться назад 20 | 21 | ### Перейти через мост 22 | 23 | Вы смело идёте по скрипящим доскам моста, но в середине пути слышите треск. Мост обрушивается под вами, и вы падаете в холодную воду реки. Вы теряете сознание... 24 | 25 | Конец игры. 26 | 27 | ### Вернуться назад 28 | 29 | Вы решаете не рисковать и возвращаетесь к развилке. 30 | 31 | Возвращение к Действию 1. 32 | 33 | ## Ветка 2: Налево 34 | 35 | 36 | Вы сворачиваете налево, и тропинка выводит вас к небольшой хижине. Из окна виден тусклый свет, а дверь приоткрыта. 37 | 38 | ### Действие 2: 39 | 40 | - Войти в хижину 41 | - Постучать в дверь 42 | 43 | ### Войти в хижину 44 | 45 | Вы решаете войти в хижину, но как только переступаете порог, дверь захлопывается за вашей спиной. Внутри пусто, только звук капающей воды раздается в тишине. Кажется, что вы попали в ловушку. 46 | 47 | Конец игры. 48 | 49 | ### Постучать в дверь 50 | 51 | Вы стучите в дверь, и через мгновение её открывает пожилая женщина с добрым взглядом. Она предлагает вам войти и отдохнуть. Вы чувствуете себя в безопасности и продолжаете путь с новыми силами. 52 | 53 | Конец игры. 54 | 55 | -------------------------------------------------------------------------------- /backend/node.js/currencies-bot/README.md: -------------------------------------------------------------------------------- 1 | # Второе задание: бот для получения курса валют 2 | 3 | Необходимо создать телеграм-бота для получения актуального курса валют. 4 | 5 | ## User Flow 6 | 7 | **1. Начало взаимодействия:** 8 | 9 | Пользователь заходит в чат бота в Telegram и пишет команду /start. 10 | Бот приветствует пользователя и предлагает команду для получения текущих курсов валют: 11 | 12 | 13 | Пример приветствия бота: 14 | 15 | ``` 16 | Привет! Я помогу тебе узнать текущие курсы валют. 17 | Напиши /currency для получения списка доступных валют. 18 | ``` 19 | 20 | **2. Выбор валюты:** 21 | 22 | - Пользователь вводит команду `/currency`. 23 | 24 | - Бот запрашивает у пользователя, какую валютную пару он хочет узнать (например, USD к EUR). 25 | 26 | 27 | Пример сообщения от бота: 28 | 29 | ``` 30 | Введи валютную пару в формате USD-EUR, чтобы узнать курс обмена. 31 | ``` 32 | 33 | **3. Получение данных:** 34 | 35 | - Пользователь вводит валютную пару, например USD-EUR. 36 | 37 | - Бот делает запрос к внешнему API (например, [Exchange Rates API](https://exchangeratesapi.io/documentation/)) для получения текущего курса валют. 38 | В случае успешного запроса бот отвечает пользователю текущим курсом. 39 | 40 | Пример сообщения от бота: 41 | 42 | ``` 43 | Текущий курс USD к EUR: 1.10. 44 | ``` 45 | 46 | **4. Ошибки и обработка исключений:** 47 | 48 | - Если пользователь введет неверный формат валютной пары, бот уведомляет о необходимости правильного ввода. 49 | - Если внешний API недоступен, бот сообщает пользователю об ошибке и просит попробовать позже. 50 | 51 | ``` 52 | Ой! Что-то пошло не так. Убедись, что ввел валютную пару в формате USD-EUR, или попробуй позже. 53 | ``` 54 | 55 | ## Требования 56 | 57 | 1. Разрешается использовать только node.js без дополнительных фреймворков. 58 | 59 | 2. Нельзя использовать готовые библиотеки для интеграции с сервисом, предоставляющим курсы валют. Вместо этого необходимо создавать HTTP-запросы для взаимодействия с внешними API (например, через HTTP-клиент axios). 60 | 61 | 3. Код должен быть асинхронным для обработки операций, таких как HTTP-запросы и взаимодействие с Telegram API. 62 | 63 | 4. Токен для телеграм бота должен конфигурироваться через файл конфигурации и может быть заменен на другой. 64 | 65 | 5. Нужно обеспечить гибкость кода для случая замены или добавления еще одного провайдера бота и сервиса для получения курсов валют (см. [Подсказки](#подсказки-и-ресурсы)). 66 | 67 | 6. Необходимо логировать: 68 | 69 | - запросы к API курса валют и ответы на них 70 | 71 | - ошибки на уровне бота 72 | 73 | 7. Необходимо протестировать флоу обработки запроса на получение курса валют, используя мок для ответа от внешнего сервиса. Тесты должны охватывать успешные результаты, а также случаи с ошибками: 74 | - при некорректном вводе от пользователя 75 | - при проблемах с подключением к внешнему сервису 76 | - при ошибке в ответе от сервиса 77 | 78 | 8. Файл README.md должен содержать краткое описание проекта и инструкцию по запуску и тестированию проекта. 79 | 80 | ## Подсказки и ресурсы 81 | 82 | Для написания проекта понадобятся следующие теоретические знания: 83 | 84 | **1. Dependency Injection (DI):** 85 | 86 | Использование dependency injection поможет разделить логику бизнес-слоя и конкретные реализации сервисов, инкапсулировать детали реализации провайдера и обеспечить модульность и расширяемость. 87 | 88 | - [A Practical Introduction To Dependency Injection](https://www.smashingmagazine.com/2020/12/practical-introduction-dependency-injection/) 89 | 90 | - [Перевод: Практическое введение во внедрение зависимостей (Dependency Injection)](https://webdevblog.ru/prakticheskoe-vvedenie-vo-vnedrenie-zavisimostej-dependency-injection/) 91 | 92 | -------------------------------------------------------------------------------- /backend/node.js/dex-sniper-bot/README.md: -------------------------------------------------------------------------------- 1 | # Пятое задание (итоговое): Снайпер-бот для Telegram 2 | 3 | Снайпер-бот для Telegram позволяет пользователям автоматизировать торговлю на децентрализованных биржах (Uniswap, PancakeSwap) в сетях Binance Smart Chain (BSC) и Polygon. Пользователи могут создавать кошельки, отслеживать адреса токенов, подписываться на сделки других адресов и автоматически повторять их. В случае нехватки средств для выполнения сделки бот уведомляет пользователя через Telegram. Также предусмотрена возможность перевода токенов между кошельками. 4 | 5 | ## User Flow 6 | 7 | **1. Регистрация и создание кошелька:** 8 | 9 | - Пользователь регистрируется в боте. 10 | - Бот создает новый кошелек в сети BSC или Polygon и отправляет пользователю адрес кошелька. 11 | 12 | **2. Управление токенами:** 13 | 14 | - **Добавление токенов:** Пользователь может отправить команду в Telegram для добавления до 5 адресов токенов, которыми он собирается торговать. Команда выглядит как: `/addtoken [адрес токена]`. Каждый раз, когда добавляется токен, бот подтверждает добавление и показывает текущий список. 15 | 16 | - **Просмотр балансов:** Пользователь может запросить балансы этих токенов, отправив команду `/balance`. Бот возвращает текущие балансы для каждого токена. 17 | 18 | - **Редактирование списка токенов:** Пользователь может удалить токен из списка командой `/removetoken [адрес токена]` или очистить весь список, если захочет заменить токены. 19 | 20 | **3. Подписка на сделки:** 21 | 22 | - **Выбор адреса для отслеживания:** Пользователь может подписаться на другой кошелек, чтобы дублировать его сделки. Команда для этого выглядит как: `/follow [адрес кошелька]`. 23 | 24 | - **Настройка повторных сделок:** Пользователь может указать, какие сделки он хочет повторять, используя команду `/replicate [buy/sell] [лимит суммы]`. Эта команда позволит пользователю контролировать, какие сделки (покупки или продажи) бот будет дублировать и на какую сумму (например, не превышать определённый лимит). 25 | 26 | - **Просмотр подписок:** Пользователь может просмотреть активные подписки на кошельки с командой `/subscriptions`. 27 | 28 | - **Удаление адреса из подписок:** Пользователь может отписаться от кошелька, тем самым отключив дублирование сделок с этого адреса. Команда для этого выглядит как: `/unfollow [адрес кошелька]`. 29 | 30 | **4. Автоматическое повторение сделок:** 31 | 32 | Когда бот обнаруживает сделку на отслеживаемом кошельке (на Uniswap или PancakeSwap), он автоматически дублирует сделку на кошельке пользователя, если это соответствует условиям подписки и настроек. 33 | 34 | **5. Оповещение при недостатке баланса:** 35 | 36 | - Если у пользователя недостаточно средств для повторения сделки, бот уведомляет его через Telegram. 37 | 38 | **6. Перевод токенов:** 39 | 40 | - Пользователь может перевести токены на другой кошелек с помощью команды `/send [адрес токена] [сумма] [адрес получателя]`. Бот подтверждает успешный перевод и уведомляет пользователя. 41 | 42 | 43 | ## Требования 44 | 45 | 1. Проект должен быть разработан с использованием NestJS фреймворка и TypeORM для работы с базой данных. 46 | 47 | 2. Для взаимодействия с блокчейнами Binance Smart Chain (BSC) и Polygon необходимо использовать библиотеку viem. 48 | 49 | 3. Параметры подключения к базе данных и блокчейн-сетям, а также другие конфигурационные параметры (например, порты сервера) должны настраиваться через конфигурационный файл и могут быть изменены без внесения изменений в код. 50 | 51 | 4. Нужно обеспечить возможность легкого расширения функционала, включая добавление новых сетей или изменение логики бота. 52 | 53 | 5. Необходимо логировать ошибки, возникающие при взаимодействии с базой данных, блокчейном и при выполнении операций через Telegram API. 54 | 55 | 6. Проект должен содержать набор тестов (unit и integration), а также инструкции для их запуска. 56 | 57 | 7. Файл README.md должен содержать краткое описание проекта и инструкции по запуску и тестированию проекта. 58 | 59 | ## Подсказки и ресурсы 60 | 61 | Для написания проекта понадобятся следующие теоретические знания: 62 | 63 | **1. Библиотека Viem** 64 | 65 | * [Viem Documentation](https://viem.sh/docs/getting-started) 66 | -------------------------------------------------------------------------------- /backend/node.js/tasks-manager/README.md: -------------------------------------------------------------------------------- 1 | # Третье задание: Таск-менеджер для команды 2 | 3 | Создание API-сервиса для управления задачами внутри команды. Пользователи могут создавать проекты, добавлять задачи с привязкой к проектам, назначать исполнителей, менять статусы задач, и просматривать результаты работы. Это задание реализуется на базе Express, Prisma и PostgreSQL, с REST-архитектурой и поддержкой CRUD операций. 4 | 5 | ## User Flow 6 | 7 | **1. Регистрация пользователя:** 8 | 9 | - Пользователь отправляет запрос на регистрацию (с именем и email). 10 | 11 | - Получает ID и токен для последующих действий. 12 | 13 | 14 | **2. Создание проекта:** 15 | 16 | - Пользователь отправляет запрос для создания проекта. 17 | 18 | - В теле запроса: название проекта и краткое описание (опционально). 19 | 20 | - Проект сохраняется в базе данных с привязкой к пользователю. 21 | 22 | 23 | **3. Добавление задачи в проект:** 24 | 25 | - Пользователь отправляет запрос для создания задачи в определенном проекте. 26 | 27 | - В теле запроса: название задачи, описание (опционально), и срок выполнения. 28 | 29 | - Задача сохраняется в базе данных с привязкой к проекту. 30 | 31 | 32 | **4. Назначение исполнителя задачи:** 33 | 34 | - Пользователь отправляет запрос на назначение исполнителем конкретной задачи. Назначить себя исполнителем может только тот пользователь, который отправил запрос. 35 | 36 | - Задача обновляется в БД с привязкой к новому исполнителю. 37 | 38 | 39 | **5. Изменение статуса задачи:** 40 | 41 | - У задачи есть статус "создана", "в процессе", "завершена". 42 | 43 | - Пользователь отправляет запрос для изменения статуса задачи (например, с «в процессе» на «завершена»). Поменять статус может только исполнитель задачи. 44 | 45 | - Сервис обновляет статус задачи в базе данных, и если задача завершена, фиксирует в бд время, затраченное на выполнение. 46 | 47 | 48 | **6. Просмотр всех проектов и задач:** 49 | 50 | - Пользователь отправляет запрос для получения списка своих проектов и связанных с ними задач. 51 | 52 | - В ответе приходит список всех проектов пользователя с краткой информацией по каждой задаче (например, статус и исполнитель). 53 | 54 | 55 | **7. Просмотр времени работы одного разрабочика:** 56 | 57 | - Любой пользователь может запросить время работы одного разработчика и отфильтровать по проектам и временным интервалам. 58 | 59 | Например: 60 | 61 | - все проекты за месяц 62 | - один проект за последнюю неделю 63 | 64 | 65 | **8. Просмотр полного времени работы над проектом:** 66 | 67 | - Любой пользователь может запросить общее время работы всех разработчиков над конкретным проектом за указанный период: за всё время, за месяц или за неделю. 68 | 69 | 70 | ## Требования 71 | 72 | 1. Проект должен быть разработан с использованием Express.js фреймворка и Prisma ORM. 73 | 74 | 2. API должно соответствовать архитектуре REST. 75 | 76 | 3. Параметры подключения к базе данных, а также другие конфигурационные параметры (например, порты сервера) должны настраиваться через файл конфигурации и могут быть изменены без изменений в коде. 77 | 78 | 4. Нужно обеспечить гибкость кода для случая замены или расширения функционала. 79 | 80 | 5. Необходимо протестировать следующие флоу: регистрация, создание проекта, создание и изменение задач. Тесты должны охватывать успешные результаты, а также случаи с ошибками, такими как: 81 | 82 | - При некорректном вводе данных (например, пустое название задачи) 83 | 84 | - При проблемах с базой данных (например, невозможность подключиться) 85 | 86 | - При нарушении целостности данных (например, задача привязана к несуществующему проекту) 87 | 88 | 6. Необходимо логировать ошибки, возникающие при взаимодействии с базой данных и в ходе работы API. 89 | 90 | 7. Проект должен содержать набор скриптов или Postman-коллекцию с запросами для тестирования эндпоинтов. 91 | 92 | 8. Файл README.md должен содержать краткое описание проекта и инструкцию по запуску и тестированию проекта. 93 | 94 | ## Подсказки и ресурсы 95 | 96 | Для написания проекта понадобятся следующие теоретические знания: 97 | 98 | **1. Express framework** 99 | 100 | * [Express Documentation](https://expressjs.com/en/5x/api.html) 101 | 102 | **2. PostgreSQL and SQL** 103 | 104 | * [Документация к PostgreSQL: Предисловие, глава I, глава II](https://postgrespro.ru/docs/postgresql/16/index) 105 | 106 | **3. Prisma ORM** 107 | 108 | * [Prisma ORM Overview](https://www.prisma.io/docs/orm/overview/introduction) 109 | 110 | **4. Аутентификация и авторизация** 111 | 112 | - [Идентификация, аутентификация и авторизация — в чем разница?](https://www.kaspersky.ru/blog/identification-authentication-authorization-difference/29123/?srsltid=AfmBOore6h53KL0_pcwY2JyTvvjCeyjQczQEadYXKI3Lb8HgfA7aTaCn) 113 | 114 | - [Введение в API. Глава 4: Аутентификация, часть 1](https://systems.education/api-auth-1) 115 | 116 | - [Введение в API. Глава 4: Аутентификация, часть 2](https://systems.education/api-auth-2) 117 | 118 | - [Introduction to JSON Web Tokens](https://jwt.io/introduction) 119 | 120 | **5. Rest API** 121 | 122 | - [Введение в API. Глава 6: Проектирование API](https://systems.education/api-design) 123 | 124 | - [REST API Tutorial](https://restfulapi.net/) -------------------------------------------------------------------------------- /backend/node.js/voting-poll-system/README.md: -------------------------------------------------------------------------------- 1 | # Четвёртое задание: Система голосований 2 | 3 | Платформа для создания и участия в опросах или голосованиях. Пользователи могут создавать опросы с разными типами вопросов (мультивыбор, одиночный выбор), а другие могут голосовать. 4 | 5 | ## User Flow 6 | 7 | **1. Регистрация и авторизация пользователя:** 8 | 9 | Пользователь создает аккаунт, вводя свои данные (имя, email, пароль), после чего получает JWT-токен для дальнейшего доступа к системе. 10 | 11 | **2. Авторизация пользователя:** 12 | 13 | Пользователь вводит свои учетные данные для входа, получает JWT-токен и доступ к возможностям платформы (создание и участие в опросах). 14 | 15 | **3. Создание опроса:** 16 | 17 | Авторизованный пользователь может создать новый опрос, заполнив название, описание, вопросы и варианты ответов. Опрос сохраняется в базе данных и становится доступным для других пользователей. 18 | 19 | **4. Просмотр списка опросов:** 20 | 21 | Пользователи могут просматривать список всех доступных опросов с краткой информацией о каждом из них. 22 | 23 | **5. Участие в опросе:** 24 | 25 | Пользователь выбирает опрос, отвечает на вопросы и отправляет свои ответы. После отправки ответы сохраняются в базе данных, и статистика обновляется. 26 | 27 | **6. Просмотр результатов опроса:** 28 | 29 | Пользователь может в любое время просмотреть результаты опроса в реальном времени — текущее распределение голосов по вариантам ответа. 30 | 31 | **7. Управление своими опросами:** 32 | 33 | Авторизованный пользователь может просматривать созданные им опросы, редактировать их или закрывать для дальнейшего участия. 34 | 35 | **8. Завершение опроса:** 36 | 37 | Владелец опроса может завершить опрос, сделав его неактивным для участия, и опрос больше не будет отображаться в списке доступных. 38 | 39 | ## Требования 40 | 41 | 1. Проект должен быть разработан с использованием Nest.js фреймворка и TypeORM. В качестве базы данных используется PostgreSQL. 42 | 43 | 2. Параметры подключения к базе данных, а также другие конфигурационные параметры (например, порты сервера) должны настраиваться через файл конфигурации и могут быть изменены без изменений в коде. 44 | 45 | 3. Необходимо протестировать логику всех эндпоинтов. Тесты должны охватывать успешные результаты, а также случаи с ошибками. 46 | 47 | 4. Необходимо логировать ошибки, возникающие при взаимодействии с базой данных и в ходе работы API. 48 | 49 | 5. Проект должен содержать набор скриптов или Postman-коллекцию с запросами для тестирования эндпоинтов. 50 | 51 | 6. Должна быть реализована документация API с использованием Swagger. 52 | 53 | 7. Файл README.md должен содержать краткое описание проекта и инструкцию по запуску и тестированию проекта. 54 | 55 | ## Подсказки и ресурсы 56 | 57 | Для написания проекта понадобятся следующие теоретические знания: 58 | 59 | **1. Nest.js framework** 60 | 61 | * [Nest.js Documentation](https://docs.nestjs.com/) 62 | 63 | **2. TypeORM** 64 | 65 | * [Typeorm Documentation](https://docs.nestjs.com/recipes/sql-typeorm) 66 | -------------------------------------------------------------------------------- /bad-indents-example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/fullstack-development/educational-program/1a38f947b6369b46865809574b9ae1e78b6f335b/bad-indents-example.png -------------------------------------------------------------------------------- /fontend-faq.md: -------------------------------------------------------------------------------- 1 | # FAQ по программе обучения. Frontend 2 | 3 | 1. **Так а сколько всё же стоит обучение?** 4 | 5 | Нисколько. Абсолютно. Полностью. Всё обучение для вас совершенно бесплатно. 6 | 7 | 2. **Оплачивается ли стажировка/есть ли стипендия и т.п.?** 8 | 9 | Стажировка не оплачиваемая. И на данный момент компания не рассматривает внедрение стипендиальных выплат. 10 | 11 | 3. **А сколько в среднем уходит на прохождение программы с нуля?** 12 | 13 | Сильно зависит от самого обучающегося. Но, в среднем, выпускники затрачивали около 1 года на прохождение программы. 14 | 15 | 4. **Какая зарплата после прохождения?** 16 | 17 | Для Junior-1, только закончивших программу обучения, ставка 200р. (+50р для Haskell разработчиков) в час на руки (после вычета всех налогов). В команде есть внутренняя карта развития разработчика, по которой можно прокачивать уровень знаний и зарплаты соответственно. Выпускник программы проходит собеседование на Junior-1. Сама карта [вот здесь](https://github.com/fullstack-development/developers-roadmap). 18 | 19 | 5. **Гарантируете ли вы трудоустройство?** 20 | 21 | На данный момент компания не гарантирует трудоустройство к себе в команду, выпускники добавляются в кадровый резерв и им делается оффер при наличии вакансии. Либо организуем собеседование в компанию партнёров, при наличие от них запроса и желания выпускника. 22 | 23 | 6. **А могу я перейти на другое направление обучения? Например, бэка на фронт, если совсем не пойдет или выбирать можно один раз?** 24 | 25 | Конечно! Вы можете перейти на frontend из backenda, или из backenda на frontend в любой момент. 26 | 27 | 7. **А когда можно приступать к обучению, и где фиксируется то, что я начал обучаться и обучаюсь вообще?** 28 | 29 | Вы можете приступать к обучению сразу после заполнения формы и получению доступа к материалам программы обучения. А по отчётам и активности в чате (исключая флуд) мы понимаем что вы проходите программу. 30 | 31 | 8. **А где посмотреть задание?** 32 | 33 | Дублируем ссылки здесь. Задания одинаковые, они просто ведут на разные ресурсы: 34 | 35 | Coda: https://coda.io/@metalamp/education/front-end-2 36 | 37 | Rizzoma: https://rizzoma.com/topic/d5c429337bcaa70548fb5aeedee6d92b/0_b_8ndo_78h6v/ 38 | 39 | Также, чтобы найти задания, вы можете воспользоваться: 40 | 41 | * Описанием телеграмм чата, там указаны ссылки, которые ведут на задания. Они также дублируют друг друга, просто ведут на разные ресурсы. 42 | 43 | * Закрепленными сообщениями в чате. 44 | 45 | * Ссылкой на задания в форме, которую вы заполняли. 46 | 47 | 9. **Обязательны ли отчёты?** 48 | 49 | Отчёты носят рекомендательный характер, но они помогают нам понять не застрял ли человек где-то и не забросил ли программу вовсе; сам ли выполнял задания (бывали и случаи плагиата работ). Поэтому мы просим стажеров писать отчёты. Наш заочный способ познакомиться возможно с будущими коллегами :) 50 | 51 | 10. **А как фиксируется прохождение мной заданий обучения?** 52 | 53 | Как таковой чёткой фиксации выполнения заданий у нас нет. Никто ни за кем пристально не следит и мы рассчитываем на вашу самостоятельность. :) 54 | 55 | Наша система построена на ежедневных отчётах и уже перед процессом код-ревью (последние шаги программы), мы будем смотреть на то, как у вас проходило обучение. 56 | 57 | 11. **Куда отправлять отчёты?** 58 | 59 | В телеграмм канал согласно вашему текущему заданию (Для фронта). Для бэкенда все отчёты отправляйте в один телеграмм канал ([канал по Haskell](https://t.me/learn_haskell_with_fsd)). 60 | 61 | 12. **А если у меня возникнут вопросы по материалу, к кому мне можно будет обратиться?** 62 | 63 | Можете смело писать интересующие вас вопросы в телеграмм чат и спрашивать у комьюнити. Также вы можете задать свой вопрос менеджеру программы обучения (администратор чата в телеграме) написав ему в личку или в телеграмм чате (поставив @ и ник менеджера.) 64 | 65 | >Не забудьте проверить через поиск по чату свой вопрос. Вдруг его уже задавали до вас и вы можете легко найти ответ 66 | 67 | 13. **Хочу начать обучение, нужно ли мне что-то скачивать/устанавливать для этого?** 68 | 69 | Нет, на начальном этапе, когда идёт знакомстве с теорией, вам ничего устанавливать не нужно. 70 | 71 | 14. **А можете скинуть какой-нибудь проект, который бы включал выполнение всех задач, требований, которые нам надо выполнить?** 72 | 73 | Мы не скрываем проекты других обучающихся, но и идеальный вариант тоже скинуть не можем. Слишком велик соблазн скопировать. И некоторые так и делали, но потом у них на реальных проектах были большие сложности с самостоятельным решением задач. -------------------------------------------------------------------------------- /frontend.md: -------------------------------------------------------------------------------- 1 | ## INTRO 2 | 3 | Тут собраны задания программы обучения по Frontend 4 | 5 | У каждого задания есть свой чатик в телеграм для общения и вопросов. 6 | 7 | Объявлять кому-то о начале своего обучения не нужно. Вам достаточно просто оставить свой первый отчёт в телеграмм чат соответствующего задания, так мы поймем что вы приступили к обучению. 8 | 9 | В этом же доке вы можете найти другие полезные материалы по программе обучения: 10 | 11 | 1) [FAQ по программе обучения для первого этапа.](./fontend-faq.md) 12 | 13 | 2) [Список с наиболее распространенными ошибками стажеров на этапе код-ревью](./popular-issues.md) 14 | 15 | ### Введение и структура курса 16 | 17 | Задания разбиты на 5 этапов. Ниже приведены средние сроки прохождения каждого этапа при активном изучении по 30-40 часов в неделю: 18 | 19 | * [1 задание](#task1) — 1-3 недели 20 | * [2 задание](#task2) — 2-4 месяца 21 | * [3 задание](#task3) — 3-4 недели 22 | * [4 задание](#task4) — 1-2 месяца 23 | * [5 задание](#task5) — 3-6 месяцев 24 | * [6 задание](#task6) — 2,5 месяца 25 | 26 | 27 | Формат обучения нацелен на изучение основ и принципов разработки. Мы сторонники фундаментальных знаний и уверены, что без них на ранних этапах обучения в технологии лучше не лезть. Это как пытаться настроить самому всю проводку в доме не зная закона Ома :) 28 | Поэтому для начала нужно изучить базис и тогда вы сможете выбирать и осваивать фреймворки осознанно, подбирая лучший под стоящую перед вами задачу: 29 | 30 | * Вёрстку, 31 | * Инструменты сборки, 32 | * Архитектуру вёрстки, 33 | * Теорию по JavaScript, 34 | * MVC и применение его на фронте, 35 | * Написание тестов (чтобы понимать, зачем они нужны). 36 | 37 | 38 | Изучение этого материала разбито на 4 этапа с практическими заданиями, а последний 5-й — это большой рефакторинг на основе наших стандартов с созданием issues в ваших GitHub-репозиториях, а также в пятом задание вам предстоит поучаствовать в групповом проекте. 39 | Вас ждут условия, как в реальной работе: требовательные заказчики, добрый скрам-мастер, внимательный продакт-оунер, горящие дедлайны, скоростное изучение новых технологий, взаимное код-ревью, меняющиеся по ходу проекта требования и 40 | полная удовлетворенность результатами работы как итог этапа. 41 | 42 | ### Коммуникация во время обучения 43 | 44 | * Общение во время обучения проходит в Telegram-чатах (если у вас не запускается Telegram — вам необходимо использовать прокси или VPN) 45 | * Доступ к телеграм-чатам для общения по первому этапу вы найдёте в конце формы из описания первого задания — заполняйте эту форму, когда приступите к нему. В этом чате вы можете общаться с участниками и задавать вопросы по вёрстке. 46 | * Для второго и последующих этапов — аналогично отдельный чат в Телеграм. Мы просим скидывать в каждый чат небольшие отчеты каждый день, после того, как вы поработали над заданиями 47 | (если в какой-то день ничего по заданиям не делали — ничего страшного, просто ничего не отсылайте). Отчёт в свободной форме: расскажите, что делали и поделитесь своими впечатлениями. 48 | 49 | > Если вы уже знаете вёрстку или проходили курсы, то вы можете сразу перейти ко второму заданию! 50 | 51 | ### Как задавать вопросы? 52 | 53 | Вопросы — это хорошо, задавать их нужно: это поможет не только вам, но и всем кто проходит или будет проходить обучение. Помните, [глупых вопросов не бывает](https://en.wikipedia.org/wiki/No_such_thing_as_a_stupid_question). 54 | 55 | * Вопросы по задачам задавать лучше в чате, соответствующего задания. 56 | * Вопросы организационные лучше задавать в личном сообщении админам чата или менеджеру программы обучения в Telegram. 57 | * Перед любым вопросом, конечно же, смотрим сначала вопросы, которые ранее уже тут задавались, и гуглим в гугле. Если вы не нашли ответ, тогда задавайте вопрос ) 58 | 59 | 60 | 61 | Очень важно максимально точно и полно описать проблему, тут оба наречия "точно" и "полно" вставлены не просто так. Старайтесь описать проблему так, чтобы ни одна важная деталь не была упущена, а потом выпилите из вопроса все лишнее. 62 | Старайтесь задать вопрос так, чтобы не пришлось в ответ спрашивать деталей. 63 | 64 | Оформляйте код в [jsfiddle](https://jsfiddle.net/) или [codepen](https://codepen.io/) с вашей проблемой, чтобы там ее можно было найти и сразу же повторить. Там должен быть только минимальный код, описывающий проблему. 65 | Возможно, пока вы будете оформлять минимальный код, выпиливая все лишнее, вы сами и найдете проблему. 66 | 67 | Не бойтесь вставлять скриншоты (пример программы для скриншота: joxi), где показывайте интерфейс, который у вас почему-то не строится, как надо. 68 | 69 | Вставлять ссылки на свои github репозитории лучше НЕ надо — для нас тяжело разбираться по каждому вопросу сразу в контексте всего репо, так как надо будет изучить кучу контекста. 70 | Небольшие примеры кода на jsfiddle как раз лишены всего нерелевантного и там можно смотреть только на тот код, что создает проблему. 71 | 72 | Обязательно надо рассказать, что уже пробовали сделать и какое в итоге расхождение было с желаемым результатом. 73 | 74 | [Как правильно задавать вопросы - Eric Steven Raymond](https://rus-linux.net/lib.php?name=/MyLDP/histori/smart-questions-ru.html) 75 | 76 | **Перед тем, как начать выполнение заданий, мы предлагаем внимательно ознакомиться с форматом прохождения, если вы еще не проходили наш [тест](https://form.typeform.com/to/rFvSaLsY).** 77 | 78 | 79 | >По любым вопросам по программе обучения пишите Светлане в Telegram: @Lana_Dulceva 80 | 81 | ## Задание 1. Изучение вёрстки. (1-3 недели) 82 | 83 | > Если вы уже знаете вёрстку, то вы можете сразу перейти ко второму заданию! 84 | 85 | Перед началом изучения материалов — заполните небольшую [форму](https://form.typeform.com/to/SA5ncLJF?), в конце которой вы найдёте ссылку на телеграм-чат, для всех, кто приступает к первому заданию. Задавайте вопросы по ходу изучения в чате. 86 | 87 | Отчеты за первый этап присылайте в этот чат из формы выше, там же общайтесь, задавайте вопросы и помогайте другим участникам — рекомендуем. 88 | 89 | ### Описание задания 90 | 91 | В основе всей работы frontend-разработчика лежит создание интерфейсов. Первый и важный навык — умение скомпоновать внешний вид на HTML+СSS по макетам дизайнера. 92 | 93 | ### *Часть 1* 94 | 95 | Мы рекомендуем начать обучение с курса — [Stepik Веб-разработка для начинающих: HTML и CSS](https://stepik.org/course/38218/syllabus) (без последних 2-х блоков) 96 | 97 | Это не единственный обучающий ресурс по вёрстке, вы можете сами выбрать любой другой источник, главное просто свериться с содержанием курсов, чтобы не пропустить какие-то важные темы. 98 | 99 | ### *Часть 2* 100 | 101 | Вам необходимо изучить Git (систему контроля версий). Для изучения мы рекомендуем — https://githowto.com/ru 102 | 103 | ### Задание вам даст 104 | 105 | * Уверенные знания вёрстки с HTML и CSS. 106 | * Уверенное владение Git. Если вы уже владеете следующими темами, то можете по гиту пока больше не изучать и идти дальше: 107 | 108 | * Индексация 109 | * Коммиты 110 | * Ветки (Создание, переключение) 111 | * Мерж веток 112 | * Просмотр изменений между коммитами или между ветками 113 | * Разрешение конфликтов 114 | * Клонирование репозиториев 115 | * Подключение нескольких удалённых репозиториев 116 | 117 | ### Дополнительный материал к первому блоку 118 | 119 | Материалы не являются обязательными и прикладываются в качестве рекомендаций. Вы можете добавить порталы и ссылки в закладки. По мере прохождения курсов мы будем выдавать вам ссылки и порталы, где можно читать дополнительные материалы, искать ответы и следить за новостями отрасли: 120 | 121 | * Книга «HTML и CSS. Разработка и дизайн веб-сайтов» Джон Дакетт. Полная версия [тут](https://library-it.com/web/html/html-i-css-razrabotka-i-dizajn-veb-sajtov-2013/) 122 | * Книга «Новая большая книга CSS» Дэвид Макфарланд 123 | * Основа методологии БЭМ https://ru.bem.info/methodology/quick-start/ 124 | Здесь очень ясно и понятно объясняется : https://www.youtube.com/watch?v=HihYQVuH64U&t=61s 125 | * [HTML on MDN](https://developer.mozilla.org/ru/docs/Web/HTML) 126 | * [HTML и HTML5. Описание тегов по основным разделам](https://html5book.ru/html-html5/) 127 | * [Список актуальных знаний для HTML-верстальщика](https://github.com/crecotun/ui-developer-skills) 128 | 129 | 130 | 131 | По любым вопросам по программе обучения пишите Светлане в Telegram: @lana_dulceva 132 | 133 |
134 |

Материалы рекомендованные другими участниками программы обучения

 135 | 136 | 137 | * https://learn.freecodecamp.org/ — бесплатный аналог htmlacademy 138 | * http://htmlbook.ru/ — теория и есть несложные задачки на верстку (для практики полезная штука) 139 | * http://htmlbook.ru/html - по html 140 | * http://htmlbook.ru/css - по cs 141 | * https://webshake.ru/test-html/start - тест по html, проверь себя 142 | * https://code-basics.ru/languages/javascript - основы JS, интерактивный бесплатный курс 143 | * https://tproger.ru/translations/flex-properties-on-css/ - анимированое руководство по flex 144 | * http://howtocenterincss.com/ - Как отцентрировать все что угодно 145 | * https://fructcode.com/ru/courses/ - интересный сервис, есть как и база HTML/CSS, так и JS + jQuery для следующего этапа 146 | * https://webref.ru/ — хорошие туториалы по основам 147 | * https://htmlreference.io/ — инфа по html тегам 148 | * https://cssreference.io/ — инфа по css свойствам 149 | * https://flexboxfroggy.com/#ru — игра для изучения flex 150 | * https://flukeout.github.io/ - игра для изучения css селекторов 151 | * https://tpverstak.ru/flex-cheatsheet/ — хорошая шпаргалка по flex 152 | * https://frontender.info/centering-css-complete-guide/ — все о центрировании в css (много способов для разных задач) 153 | * https://git-scm.com/book/ru/v2 - настольная книга по git 154 | * https://designpub.ru/long-dash-c0b28fab6fdb - о правилах типографики в вебе 155 | * https://www.youtube.com/watch?v=Rke_Z1-nvUM&list=PL3LQJkGQtzc5rDeb7FjACNb6sOW300yA0 - Git для самых маленьких, наглядно 156 | * https://www.w3schools.com/ -- материал разбит по блокам, можно посмотреть код любого примера, после блоков есть задания на повторение пройденного 157 | * https://habr.com/ru/post/463923/ 158 | * https://flexboxfroggy.com/ Игра, позволяет изучить флексы 159 | * http://howtocenterincss.com/ – how to center in CSS. 160 | * https://www.sololearn.com/ - площадка, на которой есть курсы по различным дисциплинам, плюс есть различные тесты и задания. 161 | * https://checkio.org/ - здесь можно попрактиковаться в решении различных задач с помощью js. 162 | * Glo Academy -- полезный канал на ютубе по html/css/js/git 163 | * Еще есть хороший канал "Фрилансер по жизни". Евгений выкладывает всю информацию бесплатно. На добровольном основе можно задонатить и за это будут крутые плюшки. Не реклама. Сама смотрела его видео и узнала для себя много нового https://www.youtube.com/channel/UCedskVwIKiZJsO8XdJdLKnA 164 | * http://www.itmathrepetitor.ru/zadachi-po-html-i-css/ - задачки по верстке 165 | * https://basicweb.ru/ - Справочные и учебные материалы HTML, CSS, JavaScript, jQuery 166 | * https://learn.javascript.ru/ - современный учебник по JS 167 | * https://github.com/yoksel/common-words – Слова, часто используемые в CSS-классах (если ступор какой класс задать) 168 | * https://javarush.ru/groups/posts/2683-nachalo-rabotih-s-git-podrobnihy-gayd-dlja-novichkov - разжёвывается ГИТ досконально на простом языке 169 | * Бесплатный курс "Системы контроля версий (GIT)" на 6 часов на русском языке https://ru.hexlet.io/courses/intro_to_git 170 | * https://www.youtube.com/playlist?list=PLDyvV36pndZFHXjXuwA_NywNrVQO0aQqb - объемный скринкаст по Git от Ильи Кантор 171 | * Для изучения Git рекомендую эту игру: https://learngitbranching.js.org 172 | * http://cssgridgarden.com/#ru — игра для изучения gri 173 | * [тренажер по Git](https://learngitbranching.js.org/?demo=&locale=ru_RU) 174 | * [данный плейлист](https://www.youtube.com/playlist?list=PLDyvV36pndZFHXjXuwA_NywNrVQO0aQqb) по Git 175 |
176 | 177 | ## Задание 2. Практика вёрстки. (2-4 месяца) 178 | 179 | После того, как вёрстка освоена хотя бы в основных моментах, самое время попробовать применить все полученные знания на практике. 180 | 181 | Пройдите небольшой [опрос](https://form.typeform.com/to/yKRpSWj6) — в конце опроса вы найдёте ссылку на чат для участников второго этапа. 182 | 183 | Теперь каждый день, когда вы будете делать задания, мы просим присылать небольшое саммари по итогу дня: над чем вы работали, что получилось, с какими трудностями столкнулись. А так же задавайте вопросы и помогайте другим участникам. 184 | 185 | **Описание задания** 186 | 187 | **Макет страниц по поиску номеров в отеле находится по [ССЫЛКЕ](https://www.figma.com/file/MumYcKVk9RkKZEG6dR5E3A/)** 188 | 189 | 190 | **Если вдруг увидели сообщение "Editor limit reached", то вот вторая [ССЫЛКА](https://www.figma.com/file/xorjGw6bbI9mK7fZAMebJu/FSD-frontend-education-program.-The-2nd-task-Copy)** 191 | 192 | 193 | В макете две вкладки. На первой вкладке представлен UI Kit, а на второй вкладке сами страницы по поиску номеров отеля. Переключение между вкладками находится в левом верхнем углу, рядом со значком ладошки. 194 | 195 | 196 | _Рекомендуем познакомиться со стандартами разработки [bestpractices](https://github.com/fullstack-development/front-end-best-practices) перед началом практического задания. 197 | По данным стандартам, на 5м задании, будет проводится код-ревью ваших проектов. Имеет смысл делать сразу по этим стандартам, чтобы ревью прошло быстрее. Ссылка на стандарты продублирована сюда из 5го задания._ 198 | 199 | --- 200 | 201 | ### Требования к верстке: 202 | 203 | * Вся вёрстка должна быть выложена на Github в ваш публичный репозиторий, результатом задачи будет как раз этот репозиторий. Под каждый проект создаём новый репозиторий. 204 | Присылать ссылку на него необязательно, это можно будет сделать только в пятом задании в личные сообщения организатору. 205 | * Для второго задания выделить отдельный репозиторий (мы потом отдельные issues можем туда делать). Макет опубликовать через Github Pages: https://youtu.be/9h1UiqBuxO0, чтобы мы могли быстро проверить конечный результат. 206 | * Ссылку на Github Pages добавить в Readme проекта, чтобы мы при проверке могли быстро перейти к самой вёрстке. 207 | * С начала работы коммиты в репозиторий делать как можно чаще, минимум раз в день, когда было что-то сделано, а лучше чаще (для каждого нового блока). 208 | Не надо копить многодневную работу и сваливать это одним коммитом, для таких вещей лучше использовать ветки. Не бойтесь незаконченные изменения коммитить, в этом нет ничего страшного. 209 | * Все коммиты должны иметь осмысленные названия и быть написаны на английском языке. 210 | * Ориентироваться на последние версии Chrome и Firefox. На Safari и старые IE можно не обращать внимания для этих заданий 211 | * Все отступы и размеры элементов должны быть соблюдены, для этого во время работы используйте [расширение](https://chrome.google.com/webstore/detail/perfectpixel-by-welldonec/dkaagdgjmgdmbnecmcefdhjekcoceebi?hl=ru) 212 | * Все шрифты должны быть подключены и сгенерированы в форматах .ttf, .woff, .svg, в сервисе [Font2Web](http://www.font2web.com/) 213 | * Количество картинок должно быть минимальным: если элемент состоит из текста, он должен быть текстовым, если элемент — это просто круг, сделать его чистым css, без картинок 214 | * Все страницы должны быть по максимуму responsive ([здесь](http://g-mops.net/epica_saitama/epica_layout/index_adaptive.html) примеры чем responsive отличается от adaptive и liquid). Можно максимальной ширину сделать 1920, а минимальной 320, а между этими значениями подстраиваться под ширину страницы. 215 | * Ставить в приоритет использование современных способов создания сеток, таких как flexbox и grid. 216 | * Не использовать фреймворки для создания раскладки страницы, такие как, например, bootstrap. 217 | Это, с одной стороны, важно для нашего понимания того, что вы владеете техниками создания раскладки страницы, а с другой, будет полезно вам, так как поможет углубить ваши знания в html и css, и, также, научит решать боевые задачи связанные с созданием раскладки. 218 | * Компонентность. В стандартах будет требоваться использование [БЭМ](https://ru.bem.info/methodology/quick-start/), так что предлагаем сразу его использовать. 219 | Необходимо настроить Parcel или Webpack и шаблоны, чтобы каждый БЭМ-овский блок находился в отдельной папке (там будет шаблон самого блока и все его стили, скрипты и картинки. 220 | 221 | Затем в index.pug вы будете просто подключать самые верхние блоки, а они уже будут внутри себя импортировать вложенные блоки, где надо. 222 | 223 | Каждый отдельный элемент лучше делать отдельным БЭМ-блоком. Мы сделали [небольшой туториал по компонентной архитектуре](https://fullstack-development.gitbook.io/learn/komponentnaya-arkhitektura), где вы можете понять основные принципы. 224 | 225 | 226 | * Использовать в макетах препроцессоры по максимуму. Вам в любом случае надо будет это сделать для соблюдения предыдущего требования про компонентность, импорты и вставки компонентов друг в друга вы на сыром HTML не сделаете. 227 | Подключайте [Parcel](https://parceljs.org/) (или [Webpack](https://webpack.js.org/guides/getting-started/#using-a-configuration)), он же нужен будет для 4-го задания, и через него настройте сборку [Pug](https://gist.github.com/neretin-trike/53aff5afb76153f050c958b82abd9228) 228 | (замену HTML) и [SCSS](https://habr.com/ru/post/140612/) (замена CSS). 229 | Конкретно эти технологии просто рекомендации, можете использовать другие препроцессоры, главное, чтобы они позволяли вам сделать вкладываемые компоненты с чёткими контрактами. 230 | * Небольшие расхождения в PerfectPixel допускаются в местах, где есть неточности в макете (пример: разная ширина у одинаковых блоков). 231 | * Макет был подобран так, чтобы вы явно почувствовали типичную проблему верстки — когда есть несколько (от 3-х до 100) страниц верстки, в которых используются часто похожие (совсем похожие или с небольшими отличиями) блоки. 232 | * UI-Kit — это единый макет дизайна и единая страница верстки, с которой берут типовые блоки и используют в конечных страницах 233 | * На страницах UI-Kit responsive не требуется. 234 | * В этом задании вам нужно сверстать все элементы из макета, разбив на компоненты. То есть прямо по макету накидать на одной странице все компоненты. 235 | * Сделать отдельно сами страницы проекта по поиску номеров в отеле, где эти блоки будут использоваться. Обратите внимание, что некоторые блоки будут в немного измененных модификациях (в разных местах будут разный цвет, разные масштабы или еще что-то подобное). 236 | * Так же такие вещи, как бегунки, календари и дропдауны должны быть сделаны через JS. можете подключать какие угодно jQuery-плагины для этого (вообще ради этого макет и подбирался, чтобы был опыт экспериментов с подключением jQuery и его плагинов) 237 | * ***Проект можно сразу реализовывать с учетом наших СТАНДАРТОВ разработки. Именно на соответствие этим стандартам будет проводиться ревью проекта. [Ссылка на стандарты (best practices)](https://github.com/fullstack-development/front-end-best-practices).*** 238 | 239 | 240 | >Если есть вопросы по разработке, спрашивайте в чате задания, в Figma задавать вопросы нет смысла, потому что комменты в первую очередь видит дизайнер, а ответов у него нет. 241 | 242 | ### Задание вам даст: 243 | 244 | * Понимание, как верстать большие макеты с большим количеством одинаковых элементов. 245 | * Навыки проектировать компонентную архитектуру, где каждый блок можно переиспользовать. 246 | * Работу с препроцессорами [Pug](https://gist.github.com/neretin-trike/53aff5afb76153f050c958b82abd9228) и [SCSS](https://habr.com/ru/post/140612/). 247 | * Базовые знания БЭМ. 248 | * Навыки отзывчивой вёрстки. 249 | * Самые базовые навыки работы с JavaScript. 250 | * Базовые знания систем сборок Parcel или WebPack по выбору. 251 | * Умение подключать и настраивать шрифты так, чтобы они корректно отображались в разных браузерах. 252 | * Умение искать, подключать и настраивать JavaScript-библиотеки и jQuery-плагины в частности. 253 | * Навыки работы с макетами в Figma 254 | 255 | 256 | >По любым вопросам по программе обучения пишите Светлане в Telegram: @lana_dulceva 257 | 258 |
259 |

Дополнительные материалы:

 260 | 261 | 262 | * Хорошее [видео](https://www.youtube.com/watch?v=eSaF8NXeNsA) про Webpack. 263 | * Очень крутое [видео](https://www.youtube.com/watch?v=7i_jF66F1xM) про Webpack 264 | * Отличная [статья](https://habr.com/ru/post/524260/https://youtu.be/eSaF8NXeNsA) по настройке Webpack с нуля 265 | * Подробная [статья](https://hackernoon.com/a-tale-of-webpack-4-and-how-to-finally-configure-it-in-the-right-way-4e94c8e7e5c1) на английском по настройке 266 | * Очень подробный аж целый [онлайн учебник](https://survivejs.com/webpack/foreword/) по настройке и работе сборщика 267 | * Пример сборки простого статического сайта с помощью webpack 4 https://m.habr.com/ru/post/350886/ 268 | * [CSS Architecture](https://philipwalton.com/articles/css-architecture/) ([перевод](https://web-standards.ru/articles/css-architecture/)) — рекомендации по структуре вашего CSS-кода 269 | * Обзор редакторов кода и плагины к ним: https://htmlacademy.ru/blog/40-editors-for-the-coders (рекомендуем использовать VSCode или WebStorm) 270 | * [Словарь терминов по фронтенду](https://github.com/web-standards-ru/dictionary/blob/master/dictionary.md#словарь-терминов-по-фронтенду) (так же стоит посмотреть [MDN Web Docs Glossary: Definitions of Web-related terms](https://developer.mozilla.org/en-US/docs/Glossary)) 271 | * https://github.com/kizu/bemto — удобный инструмент для написания кода по БЭМ-методологии в связке с Pug 272 | * В EMMET есть встроенный функционал для [BEM](https://docs.emmet.io/filters/bem/), если совместить с [Prettier Pug Plugin](https://github.com/prettier/plugin-pug), то становится совсем хорошо. 273 | * Подкасты: 274 | * Frontend Weekend: https://soundcloud.com/frontend-weekend 275 | * Frontend Юность: https://soundcloud.com/frontend_u 276 | * LoftBlog: https://soundcloud.com/loftblog 277 | 278 |
279 | 280 | ## Задание 3. Изучение JavaScript. (3-4 недели) 281 | 282 | Поздравляем вас с выполнением второго задания — оно самое объёмное из всех заданий программы! Впереди JavaScript, ревью-кода, командный этап и личная беседа для проверки ваших знаний. 283 | 284 | Перед тем, как вы приступите к выполнению 3 или 4 задания, [поделитесь с нами впечатлениями](https://form.typeform.com/to/R8Xdzv2M) от прохождения второго задания. 285 | 286 | В конце опроса вы найдёте ссылку на чат в [телеграме](https://t.me/fsd_frontend_3step_edu) для этого и следующего уровней. 287 | 288 | >ВАЖНО! После входа в группу нужно нажать на кнопку “Я не бот”, иначе вас выкинет из группы. 289 | 290 | ### Описание задания 291 | 292 | Как фронтенд-разработчику вам в первую очередь нужно будет решать много вопросов с кодом на JavaScript, а вёрстка будет отнимать относительно много времени только на первых порах. Так что для того, чтобы действительно быть полезными команде, вам нужно многое изучить именно в части программирования. И, естественно, первое — это стандартные возможности языка. 293 | 294 |
295 |

Полезные ссылки для изучения JavaScript:

 296 | 297 | 1. https://htmlacademy.ru/courses/javascript — если вы не проходили в первом задании курс по JS в HTML Academy, и не обладаете начальными знаниями языка, то самое время сделать это сейчас. К сожалению, только несколько самых базовых заданий сейчас оставили доступными без платной подписки. Чтобы учиться бесплатно, лучше воспользоваться другими ресурсами. 298 | 2. https://learn.javascript.ru/ — начальный ресурс по изучению языка JavaScript, на этом портале в трёх частях описаны основы языка, как минимум стоит изучить "Язык JavaScript". 299 | 3. https://learn.javascript.ru/css-for-js — отдельно обратите внимание на главу про CSS для JS-разработчиков. 300 | 4. «JavaScript. Сильные стороны.» Д.Крокфорд — мы готовы взять на работу только тех ребят, кто посчитал нужным уделить немного времени, чтобы осилить эти менее 150 страниц качественных рекомендаций. (некоторые периферийные фичи можно пропустить, например, главу про регулярные выражения и приложения Г и Д). Книга написана ещё до появления ES6, однако почти все моменты из книги до сих пор встречаются на практике либо в коде проекта, либо в коде библиотек, так что знать про это нужно обязательно 301 | 5. «Секреты JavaScript ниндзя» Дж.Резиг, Беэр Бибо 302 | 6. «JavaScript. Подробное руководство» Д.Флэнаган, советуем хотя бы 4 самые полезные главы про сам JavaScript: от 6-ой до 9-ой включительно. 303 | 7. [Codewars](https://www.codewars.com) — ресурс с интересными задачками на разных языках. Много полезных упражнений, все разделены по уровням сложности. Крайне рекомендуем после выполнения задания ознакомиться с решениями других ребят, часто там можно встретить так нужные новичку best practices. 304 | 8. [Watch and Code](https://watchandcode.com/) — на ресурсе есть бесплатные курсы про JS 305 | 306 |
307 | 308 | 309 | >Желательно несмотря на начальный уровень знаний приступать к следующему заданию параллельно с этим сразу после изучения базовых возможностей языка (переменные, функции, управляющие конструкции). Это поможет вам совместить теорию и практику, закрепить полученные знания и понять как и куда двигаться дальше. Готовьтесь к тому, что вы будете переписывать свой код на много раз (минимум 5!) — это абсолютно нормально, и даже крайне полезно с педагогической точки зрения. В реальности разработка проектов чаще состоит как раз из модификации существующего кода, а не из написания абсолютно нового, поэтому навык рефакторинга крайне полезен с самых первых месяцев работы. 310 | 311 | 312 | 313 | ### Задание вам даст 314 | 315 | * Уверенные знания самого языка JavaScript, а именно: 316 | * управляющие конструкции (циклы, условия); 317 | * основы создания и вызова функций; 318 | * контекст вызова функций (this); 319 | * области видимости/замыкания; 320 | * работу с массивами: 321 | * разные способы конструирования массивов; 322 | * разные способы вставки элементов в массив; 323 | * разреженные массивы; 324 | * переборы массивов через управляющие конструкции; 325 | * переборы массивов через методы filter/map/reduce; 326 | * добавление свойств массивам; 327 | * объекты ведущие себя как массивы (например, arguments); 328 | * методы (indexOf, shift, splice, slice, join, split, reverse, sort, concat); 329 | * работу с объектами: 330 | * объекты как ассоциативные массивы; 331 | * работа с ключами объектов (назначение, удаление, проверка существования); 332 | * создание через литералы и через конструкторы; 333 | * переборы свойств объектов; 334 | * передача объектов по ссылкам; 335 | * методы объектов; 336 | * конструкторы, дескрипторы, геттеры и сеттеры; 337 | * наследование через прототипы: 338 | * В том числе нюансы разных способов наследования. 339 | * работа с таймаутами; 340 | * броски и перехваты исключений; 341 | * работа со временем. 342 | 343 | 344 | >По любым вопросам по программе обучения пишите Светлане в Telegram: @lana_dulceva 345 | 346 | ## Задание 4. Практика JavaScript. (1-2 месяца) 347 | 348 | *Это последнее самостоятельное задание перед ревью. Чат для отчетов остаётся прежним — из 3-его задания.* 349 | 350 | ### Описание задания 351 | 352 | Задание заключается в написании плагина для jQuery, который бы реализовывал функционал «бегунка» (также называемого слайдером) — специальный контрол, который позволяет перетягиванием задавать какое-то числовое (будет круто, если в реализации можно сделать не только числовое) значение. 353 | 354 | Этот элемент уже [использовался во втором задании](https://www.dropbox.com/s/9mi6ssxwzwxjvye/FlatUI.psd?dl=0), дизайн можно взять оттуда. 355 | 356 | --- 357 | 358 | *Перед началом практического задания рекомендуем познакомиться с стандартами разработки ([bestpractices](https://github.com/fullstack-development/front-end-best-practices)) по которым, на 5м задании, будет проводится код-ревью ваших проектов. Имеет смысл делать сразу по этим стандартам, чтобы ревью прошло быстрее. Ссылка на стандарты продублирована сюда из 5го задания.* 359 | 360 | --- 361 | 362 | ### Требования: 363 | 364 | * Плагин должен иметь удобное API для подключения его к элементам на странице и соответствовать best practices по созданию плагинов для jQuery. 365 | * Плагин должен уметь работать независимо, если подключен несколько раз на странице, не должен ломать стили остальных элементов на странице. 366 | * Плагин должен быть максимально кастомизируемым. Помимо базовых конфигов вроде мининимально, максимального и текущего значения, надо позволить настраивать: 367 | * размер шага - он может быть ЛЮБЫМ ВАЛИДНЫМ, подстраивать max или min значения слайдера под размер шага при этом не нужно, как и наоборот, не нужно подстраивать размер шага под max или min значения, 368 | 369 | >Пример невалидных значений: При min 0, а max 10, шаг не может быть 11. 370 | 371 | * вертикальный/горизонтальный вид, 372 | * одиночное значение или интервал, 373 | * возможность на лету изменить значение "снаружи" javascript-ом, 374 | * возможность включать/отключать элемент над бегунком, который показывает значение и который ползает за мышкой (при выключении просто кругляш сам только на слайдера, при включении над кругляшом элемент с цифрой). 375 | * шкала значений - элемент, который отображает диапазон значений, в пределах которого можно двигать ползунок. Минимальное значение шкалы = значению min слайдера, максимальное = значению max слайдера. Шкала должна быть интерактивной. Т.е. при клике на значение шкалы, ползунок должен перемещаться на позицию этого значения. 376 | * прогресс бар - элемент от min до значения первого ползунка, при одиночном значении, либо, от значения первого ползунка до значения второго ползунка при интервале. Узнать как выглядит [прогресс бар](https://img1.freepng.ru/20180312/qtw/kisspng-plastic-font-a-progress-bar-slider-interface-design-5aa6d4f23ddc68.2190385915208829302534.jpg) (разноцветные полоски) 377 | * отзывчивость - слайдер должен тянуться/сужаться, по ширине, вместе с растягиванием/сужением своего контейнера. 378 | * Работа на тач устройствах - слайдер должен корректно работать на тач устройствах 379 | * Для демонстрации надо сверстать демо-страницу, где будет одновременно подключено больше трёх слайдеров, каждый с разными параметрами. Рядом с каждым слайдером разместить панель конфигурирования. 380 | * Панель должна быть синхронизирована со слайдером. 381 | * Для манипуляций числовыми значениями нужно использовать input с типом number или text. 382 | * Весь код должен быть на Github в вашем публичном репозитории, результатом задачи будет как раз этот репозиторий. 383 | * Требования к ежедневности коммитов и их названиям остаются, как во втором задании: коммиты минимум раз в день, когда вы хоть что-то сделали, у всех элементов должны быть осознанные названия. 384 | * Обязательно написание кода на TypeScript. Мы используем этот язык в разработке, он помогает держать сложность больших проектов под контролем, а также выручает при проектировании. Cтарайтесь настроить tsconfig максимально строгим образом. Код тестов желательно тоже писать на TypeScript, но это нестрого обязательно. 385 | * Использовать ‘any’ разрешается только в одном случае. Когда у вас совершенно никак не получается затипизировать без использования ‘any’ и вы испробовали все возможные варианты. Также вам ОБЯЗАТЕЛЬНО нужно будет написать подробный комментарий, почему вы не смогли обойтись без использования ‘any’. 386 | * У вашего приложения должны быть четко разделенные слои приложения: 387 | * Нужно сделать отдельный слой управления данными (Model), который будет содержать бизнес-логику приложения и не производить никаких расчетов, которые нужны для отображения. 388 | * Отдельный слой для управления отображением (View) — здесь нельзя проводить никаких расчетов, относящихся к бизнес-логике. Слой должен содержать логику, связанную с отображением (например, для изменения положения ползунка слайдера на экране), а также реагировать на взаимодействие пользователя с приложением. Каждый компонент слайдера (бегунки, шкала и т. д.) должен быть представлен отдельным классом. Благодаря такой декомпозиции View, функционал будет четко разделен между subViews, а вы научитесь решать проблемы взаимодействия в рамках многоуровневой структуры. 389 | * Отдельный слой для обновления модели и отображения (Controller или Presenter). Это - единственный слой среди трех, который может иметь зависимость от других слоев. Он будет: 390 | * реагировать на сообщения от отображения о действиях пользователей и обновлять модель; 391 | * реагировать на сообщения об обновлении модели и обновлять отображение. 392 | * На выходе должно получиться подобие MVP-архитектуры с Passive View. Обязательно прочитайте про MVC архитектуру, про то, зачем она нужна, и какие у нее есть ответвления. Также изучите, как можно писать MVC-приложения на JavaScript. Вот несколько полезных источников: 393 | * https://addyosmani.com/blog/understanding-mvc-and-mvp-for-javascript-and-backbone-developers/ — описание MVC и MVP архитектур и различий между ними; 394 | * https://habrahabr.ru/post/321050/ — подробный разбор MVC, часть 1; 395 | * https://habr.com/ru/post/322700/ — подробный разбор MVC, часть 2; 396 | * https://habrahabr.ru/post/276593/ — основы архетектуры, статья довольно сложная для новичка, нормально, если вы её в первый раз не очень глубоко поймёте, а потом под конец 4-го задания ещё раз вернётесь; 397 | * Мы ожидаем, что это требование создаст больше всего проблем для вас и вызовет больше всего вопросов, зато для вас это будет самым ценным опытом — разобраться в простейших паттернах проектирования и попробовать создать что-то свое небольшое с нуля, используя такие паттерны. По возникшим вопросам (правильно сформулированные, например, по рекомендациям данным выше) вам всегда могут помочь в общих чатах нашей программы. Так что смело задавайте вопросы, экспериментируйте и готовьтесь к тотальному переписыванию кода минимум пару раз :) 398 | * Архитектура приложения должна быть задокументирована: 399 | * В README проекта нужно добавить описание вашей архитектуры. 400 | * После проектирования слоёв приложения, в README вам нужно написать, как вы отвязываете ваши слои приложений от внешних зависимостей, и осуществляете передачу данных снизу-вверх по слоям приложения. Возможно, вы обратили внимание, что получившиеся слои не являются равнозначными: есть слои с высокими уровнями абстракции, а есть — с низкими. Помимо этого, возможно, вы заметили, что каждый класс вашей архитектуры отвечает за отдельный аспект приложения. 401 | * Помимо этого, вы должны составить UML-диаграмму своего приложения, которую тоже нужно добавить в README. Программа для составления диаграммы: https://www.draw.io/ 402 | * Приложение должно быть покрыто тестами: 403 | 1. Самые основы можно почитать в главе у Кантора: https://learn.javascript.ru/testing. («В этой главе мы разберём основы автоматического тестирования. Оно будет применяться далее в задачах, и вообще, входит в “образовательный минимум” программиста.»). 404 | 2. Сами тесты обязательны к написанию, должны находиться так же в репозитории, команда запуска тестов должна быть описана в README, запуск тестов после клонирования должен быть максимально простым (в идеале выполнения одной команды `npm i && npm test` должно быть достаточно), тестами должны быть покрыты все слои вашего приложения. 405 | 3. TDD (которое в том числе немного описано у Кантора) — это когда сначала пишутся тесты, а после уже сами модули и методы. 406 | 4. Это необязательное условие, особенно допустимо его нарушить для первой версии вашей программы. Желательно потом после создания каркаса попробовать некоторую функциональность добавить пару раз с использованием техники TDD (это как раз про то, что сначала должны быть тесты, потом сам код), это поможет вам лучше почувствовать методику. 407 | * Желательно попробовать какие-нибудь новые молодежные фичи: все на ваш выбор и все необязательно. Будет круто, если сможете написать кастомные правила для линтера или небольшой сервачок, например. Но ни в коем случае не фреймворки (Angular, Ember, etc) и не React, вам нужно самим проработать MVC-архитектуру, а указанные решения навязывают сверху что и как делить в приложении. 408 | * Проект можно сразу реализовывать с учетом наших СТАНДАРТОВ разработки. Имеено на соответствие этим стандартам будет проводиться ревью проекта. 409 | [Ссылка на стандарты или best practices.](https://github.com/fullstack-development/front-end-best-practices) 410 | 411 | ### Задание вам даст 412 | 413 | * Базовые навыки проектирования (ООП, вариации MVC-архитектуры, разделение ответственности). 414 | * Навыки по созданию удобных библиотек с удобным API (интерфейсом использования для других разработчиков). 415 | * Навыки разделения конфигурирования и бизнес-логики. 416 | * Умение документировать свой продукт (описывать заложенную архитектуру, визуализировать её через UML-диаграммы). 417 | * Навыки автоматического unit-тестирования (включая TDD). 418 | 419 | >По любым вопросам по программе обучения пишите Светлане в Telegram: @lana_dulceva 420 | 421 |
422 |

Дополнительные материалы:

 423 | 424 | * Слайдеры: [Рекомендуемая для изучения статья](https://www.smashingmagazine.com/2017/07/designing-perfect-slider/), которая очень поможет разобраться с разными нюансами того, как проектировать слайдеры. Не надо слепо следовать всем советам оттуда и всем указаниям, статья дана чисто для ознакомительных целей, чтобы вы могли точечно вносить улучшения в свой слайдер, основываясь не только на своём вкусе, но и на опыте, накопленном в индустрии. 425 | * Сборщики: 426 | * [Parcel — очень быстрый бандлер, не требующий настройки](https://habr.com/ru/post/344486/) 427 | * [Руководство по организации структуры и сборке проекта с webpack](https://habr.com/ru/post/350886/) 428 | * Тестирование: 429 | * [Зачем нужны юнит-тесты](https://tproger.ru/translations/unit-tests-purposes/) 430 | * [Как, используя TDD, сократить время разработки](https://www.simbirsoft.com/blog/razrabotka-cherez-testirovanie-polza-i-vred/) 431 | * [Об использовании модульных тестов и TDD](https://eax.me/unit-testing/) 432 | * [Пример разработки «Крестиков‑ноликов» по TDD](https://bespoyasov.ru/ttt-tdd/) 433 | * Ссылки на уроки по юнит-тестам с использованием Jasmine и Karma: 434 | * Видеоуроки по Jasmine: https://www.youtube.com/watch?v=9xkfgprKTmY&list=PLY4rE9dstrJwM36wcLi4we_JfhlhgYbcB 435 | * Основы работы с Karma: https://www.youtube.com/watch?v=0jFB32IT2u0 436 | * [Настройка Karma в связке с Webpack](https://habr.com/ru/company/rambler-co/blog/278503/) 437 | * [Настройка Karma-Jasmine-Webpack-Typescript](https://developerlife.com/2019/07/06/starter-project-typescript-karma-jasmine-webpack/) 438 | * Подкасты: 439 | * Веб-стандарты: https://soundcloud.com/web-standards 440 | * RadioJS: https://soundcloud.com/radiojspodcast 441 | * Пятиминутка React: https://soundcloud.com/5minreact 442 | 443 |
444 | 445 | ## Задание 5. Рефакторинг. (3-6 месяцев) 446 | 447 | 448 | Один из заключительных этапов — большой рефакторинг на основе наших стандартов с созданием issues в ваших github-репозиториях и проверка ваших знаний на личной беседе (в офисе или через созвон) c неограниченным количеством попыток. 449 | 450 | Но перед стартом последнего этапа просим вас пройти [небольшой опрос](https://form.typeform.com/to/A8Ms1jlb). 451 | 452 | [Ссылка](https://t.me/fsd_frontend_5step_edu) для общения в чате в телеграм. 453 | 454 | >ВАЖНО! После входа в группу нужно нажать на кнопку “Я не бот”, иначе вас выкинет из группы. 455 | 456 | ### Описание задания 457 | 458 | В этом задании у нас три шага: 459 | 460 | ### ***1. Рефакторинг по нашим стандартам*** 461 | 462 | У нас сейчас есть объемный документ, куда мы собираем все полезные и нужные требования к реальным проектам, готовым к сдаче заказчикам. В документах собраны правила, которые помогают избегать нерасширяемого и не очевидного кода, и все их нужно хотя бы в общих чертах помнить, прежде чем приступать к реальным проектам. А лучший способ запомнить — попробовать исправить все свои ошибки в ваших выполненных за время обучения проектах. Для помощи вам в нахождении неточностей участники программы обучения сами создали плагин для eslint, которым вы можете воспользоваться. (берите в расчет, что плагин ещё активно тестируется, там могут быть ошибки. Не бойтесь создавать ишью в репозитории плагина, а ещё лучше сами начинайте контрибьютить в open-source, исправляя недочёты и открывая Pull Request.) 463 | 464 | >Главное — не бойтесь, что мы будем криво смотреть на недочеты в прошлом коде. Мы очень лояльно относимся к коду новичков, так как сами через это проходили :) 465 | 466 | ***Описание стандартов находится в [нашем репозитории на Github](https://github.com/fullstack-development/front-end-best-practices).*** 467 | 468 | Мы выдаем вам требования, а вы вносите по ним правки в текущие проекты. Затем после рефакторинга напишите нам в чате, что все готово. 469 | 470 | ### ВНИМАНИЕ! Перед тем, как передать нам проекты на ревью окончательно проверьте и убедитесь, чтобы ВСЕ СТАНДАРТЫ ТЩАТЕЛЬНО СОБЛЮДАЛИСЬ. Мы все равно потом будем очень внимательно смотреть ваши проекты и оставлять на все нарушения задачи, но нам не хотелось бы тратить время на банальные и скучные правки, поэтому если вы заранее по максимуму подготовите свой код, то ревьюверы будут вам благодарны, обязательно это отметят, а само ревью будет проводиться гораздо эффективней, а задачи будут гораздо интересней. 471 | 472 | 473 | ### ***2. Код-ревью*** 474 | 475 | >Прежде чем приступить к этому этапу, отправьте свои репозитории нам для проверки через вот эту [форму](https://form.typeform.com/to/h0eX7A9S) заявки на ревью проектов. Только получив эту форму, мы начнем проверку :) 476 | 477 | Обычно это довольно длительный процесс, так как тут нужна синхронизация с проверяющим и часто много правок. Проверка кода в рамках ревью будет не только на предмет наших стандартов, но и на предмет продуманной и ясной архитектуры, читаемого и понятного кода, удобного интерфейса работы с вашими функциями. 478 | 479 | Мы будем ревьюить код, как реальный проект, который нам предстояло бы долго поддерживать. Он пройдёт проверку тогда, когда будут внесены все правки. Эти же правила будут применяться и при всех ревью на реальных проектах после приема на работу. Обычно это занимает довольно много времени: приходиться проект практически полностью переписывать на два, три, иногда четыре и более раз — это нормально. Логично, что когда вы делали первую версию, у вас совсем не было опыта и вы там сделали много ошибок при проектировании и реализации. Иногда такие ошибки приводят к тому, что для исправления приходится перелопатить целую гору кода — это нормально, это случается даже в реальных проектах, где в команде есть крутые спецы. 480 | 481 | Так как ревью обычно занимает много времени и между итерациями проверок могут быть существенные паузы, мы рекомендуем вам параллельно изучать теорию по всем затронутым в программе темам по дополнительным источникам, которые мы тут не перечисляли, но которые вы можете найти сами в интернете. Например, читайте про MVC, про юнит-тестирование, про нюансы работы JavaScript, про архитектуру компонентной верстки, про навыки написания чистого кода и так далее. Мы здесь давали только минимальное количество рекомендуемой литературы, не надо ни в коем случае на этом останавливаться, продолжайте углублять по всем темам по источникам, которые вы нашли сами. И не бойтесь добавлять найденные крутые ресурсы в рекомендации в соответствующие задания здесь :) 482 | 483 | Чтобы начать процесс ревью ещё раз проведите контрольное ревью проекта по нашим стандартам, и если все правила точно соблюдены, пишите в Телеграм Светлане: @lana_dulceva. 484 | 485 | ### ***3. Интервью по теоретическим вопросам*** 486 | 487 | В [нашем репозитории с картой развития](https://github.com/fullstack-development/developers-roadmap/tree/master/frontend/junior-1) у нас подготовлены около 80 вопросов по материалам из первого и третьего задания (про изучение вёрстки и изучение JavaScript). Там мы проверяем, что вы действительно изучили весь тот материал, помогаем вам побороть [неосознанную некомпетентность](http://sergeykorol.ru/blog/competence/) через получение обратной связи от нас. Количество попыток на сдачу неограниченно, обычно уходит неделя-две, чтобы повторить изученное и ещё неделя на две-три попытки сдачи, после чего задание успешно завершается. В рамках этого шага вы действительно систематизируете все полученные знания, закрываются дыры в знаниях, которые почти наверняка у вас будут, обычно это один из самых эффективных этапов в обучении, когда каждый день на уже крепкую основу ваших знаний укладывается огромное количество нового и полезного материала. Сами вопросы вы можете посмотреть в [нашем репозитории на Github (папка junior-1)](https://github.com/fullstack-development/developers-roadmap/tree/master/frontend/junior-1). 488 | 489 | ### Требования к исправлениям: 490 | 491 | * По каждому замечанию мы будем создавать issue в вашем репозитории. Коммиты с исправлениями по каждому issue стоит называть, ссылаясь на номер ишью через #. Например, для ишью "Убрать неиспользуемые переменные" с номером 14, будет коммит, с названием типа "unused variables removed #14". Это позволит при проверке сразу увидеть, какой коммит к чему относится. 492 | * Не стоит делать большие коммиты: в идеале каждый коммит по исправлению оставленных issue должен быть в рамках данного конкретного issue. Делать несколько коммитов для одного issue, если он большой — приветствуется, делать один коммит для нескольких issue — нет. 493 | * Исправляя ошибки по оставленным замечаниям, не забывайте делать это во всем проекте (и даже в других своих проектах, пока, например, ожидаете очередную итерацию ревью), а не только в том месте, которое приводится в качестве примера. Проверяющие не всегда будут сразу находить и указывать на все места, где встречаются те или иные ошибки. Так вы сэкономите время и себе и нам: вы быстрее пройдете ревью, а мы не будем писать одно и то же несколько раз :) 494 | 495 | ### Задание вам даст 496 | 497 | * расширение и закрепление ваших познаний в области проектирования 498 | 499 | >Почти наверняка вы совершили много типичных ошибок при создании архитектуры вашей компонентной вёрстки или вашего бегунка. Мы всё тщательно изучим и дадим исчерпывающую обратную связь. Опрос прошедших наше задание показал, что главное понимание ООП и MVC как раз пришло уже во время получения фидбека и очередного переписывания своего кода. 500 | 501 | * закрепление полученных теоретических знаний; 502 | * базовые навыки командной работы (получения код-ревью и работы с ишью); 503 | * навыки написания чистого поддерживаемого кода (изучение наших стандартов, чтение ишью от проверяющих); 504 | * пошаговый рефакторинг своего кода. 505 | 506 | 507 | >По любым вопросам по программе обучения пишите Светлане в Telegram: @lana_dulceva 508 | 509 | ## Задание 6. Командный проект. (2,5 месяца) 510 | 511 | ### Описание задания 512 | 513 | 1. Этот блок совместит в себе изучение библиотеки React и получение опыта работы по гибким методологиям в команде с другими обучающимися (3-7 человек) над одним проектом. Такая команда будет формироваться из обучающихся, кто находится на этапе код-ревью (Задание 5), на проверке заданий ВТОРЫМ ревьюером. 514 | 2. Продолжительность блока — 2,5 месяца (пять 2-недельных спринтов). Работа над проектом в команде, изучение React, код-ревью заданий, а потом и сдача вопросов на Junior-1 будут идти параллельно. Таким образом, вы заполните пользой время между итерациями иногда затягивающегося код-ревью, получая новые полезные скиллы. 515 | 3. На прохождение нового блока программы необходимо выделить минимум 15 часов в неделю свободного времени, по нашим подсчетам. Идеально, если получится уделять проекту по 2-3 часа каждый день. Время в течении дня вы распределяете сами. 516 | 517 | 518 | Участие в учебном проекте может вносить ограничения на ваш привычный график, потому что необходимо будет регулярно присутствовать на созвонах всей командой в определенное время. Это время будет выбираться всеми участниками проекта таким, чтобы каждому было удобно. 519 | 520 | Если вы уже завершаете проверку обоих проектов первым ревьюером на 5-м задании и есть возможность начать работу над проектом, напишите менеджеру программы обучения Светлане в телеграм: @lana_dulceva, чтобы рассмотрели возможность поставить вас в проект раньше. 521 | 522 | Ссылки для изучения React: 523 | 524 | https://ru.reactjs.org/docs/getting-started.html - обзор документации и других ресурсов, которые могут пригодиться при первом использовании React. 525 | 526 | ### Задание вам даст 527 | 528 | 1. Опыт работы в команде по Scrum, владение популярной библиотекой React, умение применять полученные знания сразу в этом же проекте. А после трудоустройства в «FSD» вы сможете быстрее получить уровень Junior-2 по карте развития, ещё во время испытательного срока, а значит и новую ЗП. 529 | 2. Практику работы над проектом в максимально приближенных к условиям на реальном коммерческом проекте: с дедлайнами, митингами, код-ревью коллег по команде, тайм-трекером, таск-трекером, тимлидом, менеджером проекта, заказчиком, с той лишь разницей, что можно безболезненно переживать факапы (а они будут) в качестве кода, в дедлайнах, в коммуникации с заказчиком и т.д. 530 | 531 | 532 | >По любым вопросам по программе обучения пишите Светлане в Telegram: @lana_dulceva 533 | 534 |
535 |

Дополнительные материалы:

 536 | 537 | * Документация по React https://reactjs.org/docs/getting-started.html 538 | * Разница между Agile, Scrum, Kanban https://leadstartup.ru/db/scrum-kanban-difference 539 | * Про внедрение Agile в команду https://kiteproject.ru/blog 540 |
541 | 542 | ## Всякие полезности 543 | 544 |
545 | Статьи по JS 546 |
547 | Сборник самых заковыристых тем JS — JavaScript Garden 548 |
549 |
550 |
551 | Functions 552 | 560 |
561 |
562 | Objects, classes etc 563 | 575 |
576 |
577 | Other 578 | 585 |
586 |
587 | 588 | 589 | Книга [Выразительный Javascript](https://karmazzin.gitbook.io/eloquentjavascript_ru/) 590 | 591 |
592 | 30 последовательных урока по изучению базового JS (без установки библиотек, настроек вебпака и тд) 593 | 594 | * JavaScript: 30 проектов за 30 дней — подборка потрясающих видео уроков от Wes Bos 595 | * Сайт с уроками — https://javascript30.com/ 596 | * Исходный код — https://github.com/wesbos/JavaScript30 597 |
598 | 599 |
600 | Аналог html academy, только включая JS и другие языки 601 | 602 | * http://skills.itvdn.com. 603 | 604 | >HTML&CSS - состоит из 138 заданий 605 | JavaScript для начинающих - состоит из 94 заданий 606 | C# Starter - состоит из 40 заданий 607 | C# Essential - состоит из 90 заданий 608 | SQL Essential - состоит из 41 задания 609 |
610 | 611 |
612 | Пример сложной архитектуры (браузерная игра) 613 | 614 | * Сама игра: http://thefounder.biz/ 615 | * Исходники для изучения https://github.com/frnsys/the_founder 616 |
617 | 618 |
619 | React day on Frontend Racoon 620 | 621 | * Смотреть записи снизу вверх, от старых к новым, от простых к сложным: 622 | * https://vk.com/jsraccoon/reactday 623 |
624 | 625 |
626 | Вы просто проглядели весь список вверху и не читали оттуда материал к текущему моменту? Это нормально. Вот это уж точно можете прямо сейчас посмотреть 627 |
628 | 629 | * [Сатирические зарисовки на тему CSS, или Cюрпризы фронтенд-разработки](https://tproger.ru/devnull/css-gotchas/amp/) 630 |
631 | 632 |
633 | Полезные расширения для VS Code 634 | 635 | * Code Spell Checker - The goal of this spell checker is to help with catching common spelling errors while keeping the number of false positives low. 636 | * px to rem - This is an extension for Visual Studio Code that allows you to convert px to rem, and vice versa. 637 | * Local History — save last changes of the files even without Git 638 |
639 | 640 | [Генератор файлов](https://github.com/nicothin/NTH-start-project/blob/master/createBlock.js) "бэмовского" блока. Очень удобная вещь по упрощению себе жизни 641 | -------------------------------------------------------------------------------- /popular-issues.md: -------------------------------------------------------------------------------- 1 | # Наиболее распространенные ошибки стажеров на этапе код-ревью. 2 | 3 | ## Общие моменты: 4 | 5 | 1. В Readme проекта следует указывать версии плагинов, на которых его писали. 6 | 7 | 2. Неверные пути к favicons. 8 | 9 | 3. Наличие орфографических ошибок в именах переменных и т.д. Плагин SpellСhecker поможет с поиском ошибок. 10 | 11 | 4. Библиотеки лежат обычными файлами, а должны быть установлены через npm или yarn. 12 | 13 | 5. Не соблюдение нейминга файлов в стиле lowercase-hyphenated. Правило [3.1](https://github.com/fullstack-development/front-end-best-practices/blob/master/HTML/README.md#3.1). 14 | 15 | >Также стоит учитывать исключения (Пример: файл экспортирующий класс, нейминг js файлов (правило [1.4](https://github.com/fullstack-development/front-end-best-practices/blob/master/JS/README.md#1.4)). 16 | 17 | 6. Отсутствуют дефолтные значения для аргументов функций, методов класса, pug миксинов. 18 | 19 | 7. Прежде чем отключать правило линтера (// eslint-disable-next-line), разберитесь, зачем оно нужно. Не отключайте его без необходимости. И готовьтесь к тому, что вас могут попросить аргументированно обосновать своё решение; почему вы отключили данное правило. 20 | 21 | 8. Структура БЭМ блока не соответствует правилу: 1 блок - 1 директория - 1 pug (1 миксин) - 1 css - 1 js. 22 | 23 | 9. Использование элементов реализации блока из вне, и блока без pug миксина. Правило [4.4](https://github.com/fullstack-development/front-end-best-practices/blob/master/CSS/README.md#4.4). 24 | 25 | 10. Наличие BEM миксов. Правила [4.5](https://github.com/fullstack-development/front-end-best-practices/blob/master/CSS/README.md#4.5) и [4.6](https://github.com/fullstack-development/front-end-best-practices/blob/master/CSS/README.md#4.6). 26 | 11. Файл экспортирующий класс должен называться так же, как и экспортируемый класс. 27 | 28 | 12. Нельзя оставлять “закомменченный” код. Правило [1.23](https://github.com/fullstack-development/front-end-best-practices/blob/master/JS/README.md#1.23). 29 | 30 | 13. Неверная сортировка импортов. Правило [1.17](https://github.com/fullstack-development/front-end-best-practices/blob/master/JS/README.md#1.17). 31 | 32 | 14. Неверная сортировка методов класса. Правило [8.5](https://github.com/fullstack-development/front-end-best-practices/blob/master/JS/README.md#8.5). 33 | 34 | 15. Отсутствие префиксов js-. Правило [5.1](https://github.com/fullstack-development/front-end-best-practices/blob/master/JS/README.md#5.1). 35 | 36 | 16. Не модульный JS. Правило [5.5](https://github.com/fullstack-development/front-end-best-practices/blob/master/JS/README.md#5.5). 37 | 38 | 17. Неверный выбор типа BEM модификатора (булевый, ключ-значение). 39 | ``` 40 | Пример: button_type_hidden. 41 | 42 | Hidden - это булевый модификатор, свойство либо есть, либо нет. Ключ для него не нужен. Правильно - button_hidden 43 | 44 | Ключ требуется когда есть вариативность: button_size_big, button_size_middle 45 | ``` 46 | 18. Одному DOM элементу должен соответствовать один БЭМ-блок или элемент. 47 | ``` 48 | Неправильно: 49 | 50 | .calculator__button.calculator__plus 51 | 52 | Правильно: 53 | 54 | .calculator__button.calculator__button_action_plus.calculator__button_disabled 55 | ``` 56 | ## Toxin: 57 | 58 | 1. Все страницы, кроме UI kit, должны быть адаптированы под ширину от 320 до 1920 пикселей. При большой ширине (1200+) контейнер с контентом растягивать не нужно, страницы должны соответствовать макетам. При маленькой ширине (как на мобильных устройствах), для меню использовать “гамбургер”. 59 | 60 | 2. Часто встречаются ошибки в pixel perfect. 61 | 62 | 3. Частое несоблюдение стилей макета, т.е. граница у кнопки не градиентная, а сплошная; текст не полупрозрачный, а непрозрачный и т.п. 63 | 64 | 4. Отсутствует маска в masked-textfield. 65 | 66 | 5. Диаграмма на странице room-details не должна быть просто картинкой. В параметрах нужно передать список значении и построить круговую диаграмму на их основе. 67 | 68 | 6. В date-dropdown должен быть один календарь на два инпута. 69 | 70 | >Не забывайте проверять как выглядит календарь на мобильных. Если ввод дат вручную в инпуты работает некорректно, то необходимо запретить его. То же самое и для dropdown. 71 | 72 | 7. Устанавливать адекватные отступы от края экрана и между смысловыми блоками на странице. Правило [1.13](https://github.com/fullstack-development/front-end-best-practices/blob/master/CSS/README.md#1.13). 73 | 74 | Пример плохих отступов: 75 | 76 | ![bad indents example](./bad-indents-example.png) 77 | 78 | ## Slider: 79 | 80 | 1. Readme описан недостаточно полно. Отсутствует информация о том как подписаться на события слайдера и отписаться от них, с какой версией node и jQuery проект совместим. 81 | 82 | 2. Код для клиента и код для демонстрации слайдера находятся в одном продакшн бандле. На выходе код клиента и демонстрационный код должны лежать в разных файлах, чтобы клиент не грузил абсолютно ненужный ему код. Реализовать это можно созданием по одной точке для каждого типа кода. 83 | 84 | 3. jQuery находится в продакшн бандле, предпочтительнее, чтобы клиент устанавливал jQuery самостоятельно, подобрав версию, совместимую для нескольких плагинов. Можно подключить jQuery в слайдер через CDN. 85 | 86 | 4. На демо-странице для слайдера не соблюдаются стандарты (в первую очередь касается БЭМ, ооп для ts, весь код страницы не должен находиться в одном/двух файлах). 87 | 88 | 5. Слайдер ломается при передаче нестандартных значений. Также в слайдере не должны лежать невалидные значения. 89 | 90 | > Пример невалидных значений: При min 0, а max 10, шаг не может быть 11. 91 | 92 | 6. Необходимо проверять демо на ошибки. Тестировать разного рода значения: большие, маленькие, отрицательные, дробные, невалидные. 93 | 94 | ## Typescript: 95 | 96 | 1. В tsconfig должен быть установлен флаг strict: true. 97 | 98 | 2. Запрещается добавлять в tsconfig флаги, ослабляющие проверки типов, такие как, например, [suppressImplicitAnyIndexErrors](https://www.typescriptlang.org/tsconfig#suppressImplicitAnyIndexErrors), [suppressExcessPropertyErrors](https://www.typescriptlang.org/tsconfig#suppressExcessPropertyErrors) и подобные. 99 | 100 | 3. Запрещается использовать правило @ts-ignore. 101 | 102 | 4. Использовать ‘any’ разрешается только в одном случае. Когда у вас совершенно никак не получается затипизировать без использования ‘any’ и вы испробовали все возможные варианты. Также вам ОБЯЗАТЕЛЬНО нужно будет написать подробный комментарий, почему вы не смогли обойтись без использования ‘any’. 103 | 104 | 5. Запрещается использовать type assertions, в частности с помощью “as” и non-null assertion operator (оператор “восклицательный знак”). --------------------------------------------------------------------------------