Media is too big
VIEW IN TELEGRAM
Infinite Animation
В этом видео создаётся бесконечная анимация загрузки, частицы которой генерируются в JS и анимируются в CSS.
👉 @seniorFront
В этом видео создаётся бесконечная анимация загрузки, частицы которой генерируются в JS и анимируются в CSS.
👉 @seniorFront
👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Tailwind - Notifications and Messages
Небольшой компонент с сообщениями и уведомлениями, стилизованный при помощи Tailwind.
👉 @seniorFront
Небольшой компонент с сообщениями и уведомлениями, стилизованный при помощи Tailwind.
👉 @seniorFront
👍13🔥3
Что делает метод Element.closest() в JavaScript?
Anonymous Quiz
18%
Ищет и возвращает первый дочерний элемент, соответствующий указанному CSS-селектору
49%
Ищет и возвращает ближайший родительский элемент, соответствующий указанному CSS-селектору
33%
Ищет и возвращает элемент, стоящий на том же уровне, соответствующий указанному CSS-селектору
🔥12
Media is too big
VIEW IN TELEGRAM
Hover to Affect Sibling Elements
В этом видео создаётся эффект при наведении на элемент, а также создаются эффекты для соседних элементов. Для задания стилей соседним элементам используются свойства previousElementSibling и nextElementSibling.
👉 @seniorFront
В этом видео создаётся эффект при наведении на элемент, а также создаются эффекты для соседних элементов. Для задания стилей соседним элементам используются свойства previousElementSibling и nextElementSibling.
👉 @seniorFront
👍5❤2
Find Count of Most Frequent Item in an Array
Создайте функцию для нахождения количества наиболее часто встречающихся элементов массива. Можно предположить, что входными данными является массив целых чисел. Для пустого массива верните 0.
Пример:
Самое частое число в массиве это -1, оно встречается 5 раз.
👉 @seniorFront
Создайте функцию для нахождения количества наиболее часто встречающихся элементов массива. Можно предположить, что входными данными является массив целых чисел. Для пустого массива верните 0.
Пример:
input array: [3, -1, -1, -1, 2, -1, 3, -1, 2, 9, 3] ouptut: 5 Самое частое число в массиве это -1, оно встречается 5 раз.
👉 @seniorFront
👍1
Реактивность в React и Vue
В этой статье автор сравнивает реактивности данных в таких библиотеках: React.js и Vue.js. Проводит сравнение процессов ре-рендеринга страниц. Данная статья хорошо подойдёт для новичков.
👉 @seniorFront
В этой статье автор сравнивает реактивности данных в таких библиотеках: React.js и Vue.js. Проводит сравнение процессов ре-рендеринга страниц. Данная статья хорошо подойдёт для новичков.
👉 @seniorFront
🤔13👎8
Synthetic events в React
В React, "синтетические события" (synthetic events) - это система обработки событий, которая предоставляет кросс-браузерную и кросс-платформенную абстракцию над нативными событиями браузера. Они создаются и управляются React и обеспечивают более единообразное поведение обработки событий в различных браузерах.
Синтетические события предоставляются компонентам React как аргументы обработчиков событий и имеют схожий интерфейс с нативными событиями браузера, но с некоторыми различиями и улучшениями.
Пример использования синтетических событий:
В этом примере, event является синтетическим событием, передаваемым в обработчик
Синтетические события также имеют дополнительные преимущества, такие как автоматический пулинг (для оптимизации работы с памятью), нормализация различий между разными браузерами и поддержка делегирования событий.
👉 @seniorFront
В React, "синтетические события" (synthetic events) - это система обработки событий, которая предоставляет кросс-браузерную и кросс-платформенную абстракцию над нативными событиями браузера. Они создаются и управляются React и обеспечивают более единообразное поведение обработки событий в различных браузерах.
Синтетические события предоставляются компонентам React как аргументы обработчиков событий и имеют схожий интерфейс с нативными событиями браузера, но с некоторыми различиями и улучшениями.
Пример использования синтетических событий:
import React from 'react';
class Button extends React.Component {
handleClick = (event) => {
event.preventDefault();
console.log('Button clicked!');
};
render() {
return <button onClick={this.handleClick}>Click me</button>;
}
}В этом примере, event является синтетическим событием, передаваемым в обработчик
handleClick. Вы можете вызывать методы такие как preventDefault(), stopPropagation(), и другие, а также получать информацию о событии (например, event.target, event.clientX, и др.).Синтетические события также имеют дополнительные преимущества, такие как автоматический пулинг (для оптимизации работы с памятью), нормализация различий между разными браузерами и поддержка делегирования событий.
👉 @seniorFront
👍6👎1
This media is not supported in your browser
VIEW IN TELEGRAM
Blurry Text Reveal
Анимировано библиотекой gsap. Анимация запускается при прокрутке страницы.
👉 @seniorFront
Анимировано библиотекой gsap. Анимация запускается при прокрутке страницы.
👉 @seniorFront
👍7
Этот опасный рефакторинг (Как снизить риски?)
Ошибки во время рефакторинга могут дорого обойтись. Модернизация, ведущая к отказу системы, или внесение новой функциональности параллельно с ошибочными правками явно принесут вред. Но степень вреда может быть разной.
Некоторые задачи рефакторинга подразумевают крупные изменения и затрагивают несколько подсистем. Другие при этом ограничиваются одним компонентом, но могут непредвиденно повлиять на другие части системы и вызвать поломку важнейших бизнес-операций. В этом случае речь может идти о действующем потоке приобретения товара. Третья категория – это доработки, позволяющие внести новые возможности – например, изменение потока приобретения одного товара для поддержки большего числа его единиц и добавление ещё одного потока после.
Объединяет все эти сценарии то, что они сопряжены с высоким риском.
1. В случае ошибки такие доработки навредят бизнесу (потеря прибыли, недовольство клиентов), команде (подорвут доверие, мотивацию) или другим связанным функциям (разработка встанет).
2. Причём реализация этих изменений весьма затратна, так как требует повышенного внимания, усилий и времени. Предпочтительнее для таких задач задействовать опытных разработчиков, хорошо разбирающихся в этой области.
Как снизить риски
Рекомендую использовать чек-лист:
- Определите ограничения. Как далеко можно зайти?
- Изолируйте доработки от функциональности. Не применяйте их вместе.
- Напишите обширные тесты, более высокоуровневые (интеграционные) с меньшим числом деталей реализации, и сопровождайте ими внесение изменений.
- Проверьте всё наглядно. Запустите браузер.
- Не пропускайте тесты. Не ленитесь.
- Не полагайтесь слишком сильно на код-ревью и контроль качества (QA). Люди ошибаются.
- Не смешивайте масштабные зачистки с другими изменениями. Это можно делать в случае небольших доработок.
👉 @seniorFront
Ошибки во время рефакторинга могут дорого обойтись. Модернизация, ведущая к отказу системы, или внесение новой функциональности параллельно с ошибочными правками явно принесут вред. Но степень вреда может быть разной.
Некоторые задачи рефакторинга подразумевают крупные изменения и затрагивают несколько подсистем. Другие при этом ограничиваются одним компонентом, но могут непредвиденно повлиять на другие части системы и вызвать поломку важнейших бизнес-операций. В этом случае речь может идти о действующем потоке приобретения товара. Третья категория – это доработки, позволяющие внести новые возможности – например, изменение потока приобретения одного товара для поддержки большего числа его единиц и добавление ещё одного потока после.
Объединяет все эти сценарии то, что они сопряжены с высоким риском.
1. В случае ошибки такие доработки навредят бизнесу (потеря прибыли, недовольство клиентов), команде (подорвут доверие, мотивацию) или другим связанным функциям (разработка встанет).
2. Причём реализация этих изменений весьма затратна, так как требует повышенного внимания, усилий и времени. Предпочтительнее для таких задач задействовать опытных разработчиков, хорошо разбирающихся в этой области.
Как снизить риски
Рекомендую использовать чек-лист:
- Определите ограничения. Как далеко можно зайти?
- Изолируйте доработки от функциональности. Не применяйте их вместе.
- Напишите обширные тесты, более высокоуровневые (интеграционные) с меньшим числом деталей реализации, и сопровождайте ими внесение изменений.
- Проверьте всё наглядно. Запустите браузер.
- Не пропускайте тесты. Не ленитесь.
- Не полагайтесь слишком сильно на код-ревью и контроль качества (QA). Люди ошибаются.
- Не смешивайте масштабные зачистки с другими изменениями. Это можно делать в случае небольших доработок.
👉 @seniorFront
👍3
Как защитить PROD от багов и себя от стресса
Эта статья - взгляд QA на проблему возникновения багов на ПРОДе. Он выделил пять основных рисков:
1. Идея попадает к аналитику
Владелец продукта и аналитик на этапе проектирования тех. требований могут некорректно описать логику нового функционала (флоу). Заказчик имел ввиду одно, а по итогу в спецификациях совершенно другое. Решение данной проблемы может зависеть от правил взаимодействия с заказчиком в вашей команде.
Необходимо ли заказчику описывать предложения в письменном виде с точным описанием? Ответственность данного риска лежит на плечах владельца продукта и он в свою очередь может сделать общение с заказчиком более прозрачным для команды.
2. Разработка по тех. требованиям
Frontend и Backend разработчики берут задачи из бэклога в спринт, но в задаче может быть прикреплена устаревшая документация, ее может и вовсе не быть.
Пиши то - не зная что, реализуй так - не зная как.
Часто встречается и такая модель разработки - когда ответственность падает только на разработчика, минуя владельца продукта и аналитику. Это грустно и в таком случае помогут DOR и DOD.
Definition of Ready - это критерии готовности взять задачу в разработку, то есть DOR это условия, при выполнении которых задача может упасть в спринт. Команда сама выбирает критерии и придерживается их. Например: аналитика написана, есть точные тех.требования и т.д.
Definition of Done - это критерии завершения задачи, то есть условия после которых выполненная задача переходит в тестирование к QA.
3. Frontend и Backend выполняют задачи не синхронно
Под синхронным выполнением задачи я подразумеваю, что задачи на фронте и на бэке будут выполняться как минимум в одном спринте. Почему это критично? Тех.требования имеют свойства корректироваться на этапе разработки и если один разработчик взял задачу в одном спринте и подкорректировал реализацию на своей стороне, то второй разработчик может выполнить задачу по устаревшим требованиям.
4. Тестирование
Само тестирование может быть некачественным из-за человеческого фактора. Пропустил ошибку т.к. не написал тест-кейс по этой функциональности или не проверил негативные тесты. Недостаточно времени было на тестирование. Не было документации вовсе.
Данный риск зависит от самого инженера по тестированию, но описанные выше риски могу напрямую влиять на качество тестирования и ответственность ложится уже на вас.
Защитить себя и ваше время помогут вышеупомянутые DOR и DOD.
5. Релиз (Поддержка)
Данный риск зависит от четвертого, т.к. вы можете обнаружить ошибку только при регресс тестировании, а это значит мало времени уделено тестированию. В этот риск я бы добавил момент, когда вы выкатились на прод, но заказчику не нравится что-либо.
👉 @seniorFront
Эта статья - взгляд QA на проблему возникновения багов на ПРОДе. Он выделил пять основных рисков:
1. Идея попадает к аналитику
Владелец продукта и аналитик на этапе проектирования тех. требований могут некорректно описать логику нового функционала (флоу). Заказчик имел ввиду одно, а по итогу в спецификациях совершенно другое. Решение данной проблемы может зависеть от правил взаимодействия с заказчиком в вашей команде.
Необходимо ли заказчику описывать предложения в письменном виде с точным описанием? Ответственность данного риска лежит на плечах владельца продукта и он в свою очередь может сделать общение с заказчиком более прозрачным для команды.
2. Разработка по тех. требованиям
Frontend и Backend разработчики берут задачи из бэклога в спринт, но в задаче может быть прикреплена устаревшая документация, ее может и вовсе не быть.
Пиши то - не зная что, реализуй так - не зная как.
Часто встречается и такая модель разработки - когда ответственность падает только на разработчика, минуя владельца продукта и аналитику. Это грустно и в таком случае помогут DOR и DOD.
Definition of Ready - это критерии готовности взять задачу в разработку, то есть DOR это условия, при выполнении которых задача может упасть в спринт. Команда сама выбирает критерии и придерживается их. Например: аналитика написана, есть точные тех.требования и т.д.
Definition of Done - это критерии завершения задачи, то есть условия после которых выполненная задача переходит в тестирование к QA.
3. Frontend и Backend выполняют задачи не синхронно
Под синхронным выполнением задачи я подразумеваю, что задачи на фронте и на бэке будут выполняться как минимум в одном спринте. Почему это критично? Тех.требования имеют свойства корректироваться на этапе разработки и если один разработчик взял задачу в одном спринте и подкорректировал реализацию на своей стороне, то второй разработчик может выполнить задачу по устаревшим требованиям.
4. Тестирование
Само тестирование может быть некачественным из-за человеческого фактора. Пропустил ошибку т.к. не написал тест-кейс по этой функциональности или не проверил негативные тесты. Недостаточно времени было на тестирование. Не было документации вовсе.
Данный риск зависит от самого инженера по тестированию, но описанные выше риски могу напрямую влиять на качество тестирования и ответственность ложится уже на вас.
Защитить себя и ваше время помогут вышеупомянутые DOR и DOD.
5. Релиз (Поддержка)
Данный риск зависит от четвертого, т.к. вы можете обнаружить ошибку только при регресс тестировании, а это значит мало времени уделено тестированию. В этот риск я бы добавил момент, когда вы выкатились на прод, но заказчику не нравится что-либо.
👉 @seniorFront
❤2👍1🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Curious Geckos
Создано без использования JS, при помощи возможностей препроцессоров Pug и SCSS. А также CSS селектора :has. Подробное описание игры и процесса создания в статье.
👉 @seniorFront
Создано без использования JS, при помощи возможностей препроцессоров Pug и SCSS. А также CSS селектора :has. Подробное описание игры и процесса создания в статье.
👉 @seniorFront
❤3
Media is too big
VIEW IN TELEGRAM
Animated Download Button
В этом видео создаётся кнопка скачивания, анимируемая при нажатии
👉 @seniorFront
В этом видео создаётся кнопка скачивания, анимируемая при нажатии
👉 @seniorFront
👍3
This media is not supported in your browser
VIEW IN TELEGRAM
Slider with Two Different Sidebars
Слайдер реализован при помощи библиотеки Swiper. А также в JS создана логика проигрывания музыки.
👉 @seniorFront
Слайдер реализован при помощи библиотеки Swiper. А также в JS создана логика проигрывания музыки.
👉 @seniorFront
👍4
This media is not supported in your browser
VIEW IN TELEGRAM
3D wave animation
Создано на HTML и CSS. При помощи комбинатора '+' стили задаются соседним элементам.
👉 @seniorFront
Создано на HTML и CSS. При помощи комбинатора '+' стили задаются соседним элементам.
👉 @seniorFront
👍17🔥2❤1
Чем отличаются методы forEach() и map() при работе с массивами в JavaScript?
Anonymous Quiz
28%
forEach() изменяет исходный массив, а map() создает новый массив с результатами колбэка.
6%
forEach() возвращает новый массив, а map() ничего не возвращает.
67%
forEach() ничего не возвращает, а метод map() возвращает новый массив с результатами вызова колбэка.
👍19👎4
16 апреля в Айтилогии стартует 7-дневный бесплатный интенсив по frontend-разработке, на котором ты с нуля без знаний создашь фронтенд-проект на Angular 🔥
На интенсиве ты:
– Сверстаешь лендинг на HTML + CSS
– Реализуешь функционал на JavaScript
– Используешь фронтенд-фреймворк Angular
– Подключишь Backend и загрузишь сайт на хостинг
🎁 Будет общий чат, проверка домашек от экспертов, различные бонусы!
А за кодовую фразу, собранную во время интенсива, автор подарит своё резюме Senior-разработчика, с помощью которого устроился на ЗП 3500$
Первые 100 мест бесплатно, потом 6 990 руб. Не упусти👇🏻
Frontend Start
На интенсиве ты:
– Сверстаешь лендинг на HTML + CSS
– Реализуешь функционал на JavaScript
– Используешь фронтенд-фреймворк Angular
– Подключишь Backend и загрузишь сайт на хостинг
🎁 Будет общий чат, проверка домашек от экспертов, различные бонусы!
А за кодовую фразу, собранную во время интенсива, автор подарит своё резюме Senior-разработчика, с помощью которого устроился на ЗП 3500$
Первые 100 мест бесплатно, потом 6 990 руб. Не упусти👇🏻
Frontend Start
👍2👎2❤1
Media is too big
VIEW IN TELEGRAM
Responsive Contact us Page
В этом видео создается страница контактов с анимированной формой
👉 @seniorFront
В этом видео создается страница контактов с анимированной формой
👉 @seniorFront
👍6